Re: Cable Modem [really responsible engineering]
On Tue, 26 Jun 2001 09:25:08 -0700 Ted Lemon wrote:
Also, if the cable/dsl/wireless modem is a router, life becomes much simpler as one can just gather the necessary information via tracing. However, I am not sure requiring modems to be routers is a good thing...
I think you should sit down and read the DOCSIS specifications carefully before you say things like this. If implemented correctly, it actually works, believe it or not. The modem does _not_ have to be a router in order for it to work.
Ted; Thank you so much!! I will set right out to do so! regards, fletcher
On Tue, 26 Jun 2001 16:08:13 -0400 Fletcher E Kittredge wrote:
Also, if the cable/dsl/wireless modem is a router, life becomes much simpler as one can just gather the necessary information via tracing. However, I am not sure requiring modems to be routers is a good thing...
I think you should sit down and read the DOCSIS specifications carefully before you say things like this. If implemented correctly, it actually works, believe it or not. The modem does _not_ have to be a router in order for it to work.
Ted;
Thank you so much!! I will set right out to do so!
Ted; I haven't been able to figure your statement above out. I thought you were saying that given a client device MAC address, one could determine which cable modem MAC address was servicing that client MAC, even in the cases where the cable modem was just acting as a bridge. This is embarassing, but I have been spending time on the DOCSIS 1.0 spec (http://www.cablemodem.com/specifications.html), and I can't seem to find where this behavior is specified as required. Could you give me some hints as to which document it is in and which section? Given the DOCSIS specifications, the two mechanisms I can think of for yielding this information are SNMP and DHCP. In regards to DHCP, time spend with the DOCSIS spec, your excellent book and tcpdump says to me that it is not in the DCHPREQUEST packet, either as 'giaddr' or as any DHCP option I can find. Time with the RFCs and the DOCSIS spec have not yielded to me any SNMP object in any of the DOCSIS required SNMP MIB RFCs which would return all the the bridged MAC What am I missing? Your guidance is much appreciated. thanks, fletcher
[ On Thursday, June 28, 2001 at 13:41:55 (-0400), Fletcher E Kittredge wrote: ]
Subject: Re: Cable Modem [really responsible engineering]
I haven't been able to figure your statement above out. I thought you were saying that given a client device MAC address, one could determine which cable modem MAC address was servicing that client MAC, even in the cases where the cable modem was just acting as a bridge.
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: 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). 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. 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). -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
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
[ 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 <gwoods@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Thu, 28 Jun 2001 17:57:14 -0400 (EDT) Greg A. Woods wrote:
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?).
This works when the modem is on, and when you don't have a large number of modems... For a large number of modems, running that number of smtpgets when there is an active problem to be solved is not fun. How would you do historical data? How frequently would you poll the CPE to put together your history?
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?
Teach your aged grandmother to suck eggs, Greg.
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.
Ouch, the chicken thing really hurts... Did you know I was a chicken farmer? Greg, with all due respect, I have been doing all of this for longer than you :) Back around 1986, I realized that there are no original ideas in an Internetworked world. Given the same problem, people tend to come up with the same solutions. Especially since nanog readers tend to share the same paradigms... Anyhow, we tried these ideas in the early days. This conversation arises out of the problems we had. I am done with this thread; thank you. sincere regards, fletcher
[ On Friday, June 29, 2001 at 14:08:12 (-0400), Fletcher E Kittredge wrote: ]
Subject: Re: Cable Modem [really responsible engineering]
This works when the modem is on, and when you don't have a large number of modems... For a large number of modems, running that number of smtpgets when there is an active problem to be solved is not fun.
How would you do historical data?
Remember what I said about caching and updating the cache? (there should be a clue here for you -- this question always keeps coming back to the very same answer!)
How frequently would you poll the CPE to put together your history?
I wouldn't ever poll the CPE. All I ever need to know about CPE devices is in my dhcpd.leases file (and the dhcpd syslog entries).
Greg, with all due respect, I have been doing all of this for longer than you :) Back around 1986, I realized that there are no original ideas in an Internetworked world. Given the same problem, people tend to come up with the same solutions. Especially since nanog readers tend to share the same paradigms...
You think so, do you? :-) -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <woods@robohack.ca> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
participants (2)
-
Fletcher E Kittredge -
woods＠weird.com