Cable Modem [really responsible engineering]

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 :slight_smile: 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 :slight_smile: 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 :slight_smile: 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.