[nzlug] Telstra/linux

[Mathew Carley]

There you go then. That clears things up for me about how these 
new-fangled-thingamajigs work :)

Phillip Hutchings wrote:
> On 7/5/07, Mathew Carley <nzlug at mathew-carley.com> wrote:
>> As I was trying to explain, I *think* that these modems are simply
>> bridges
>
> Not even bridges, they're media convertors. All they do is convert
> ethernet over cable to ethernet over 10-BaseT, a bridge would mess
> with IP level traffic. There are some added smarts for SNMP reporting
> to the management systems and traffic shaping, but they're a very
> basic device in network terms.
>
>> I would think that if the modem is going to be set by anything, it would
>> be by TFTP based on your node id on the cable network,
>
> Mostly, and MAC address, there aren't node IDs on the c able network.
> There are some configuration options, mostly the frequency to use,
> since that can be detected incorrectly by the modem in some cases and
> make startup really slow.
>
>> itself, as it seems that the MAC addresses stored within the cable modem
>> are somehow important (MAC based routing of some sort?)
>
> MAC filtering at the head end, to make sure you can't just use a
> random cable modem and someone else's IP address. I believe the IP
> address you use is tied to the MAC of the modem in some way, but you
> can certainly send non-IP4 packets over the cable network. When I was
> on cable I had much fun with BGP4+ and IPv6 between a group of us.
> Saved on traffic in the old days, but I believe the new system would
> put an end to that.
>
>> Don't ask me how I am still able to access my modem via 192.168.100.1
>> when my ethernet cards IP address is not on that range... everything
>> from networking 101 says that it doesn't make sense and I shouldn't be
>> able to get to that address, yet I can.
>
> Unless your internal network is 192.168.100.0/24 requests to that
> address will be treated like any other request to the big bad
> internet. It's just special because the cable modem itself will
> intercept the packets and reply to them rather than simply forwarding
> to the cable network.
>