Spent most of the day on a Cinemon support on-site call. The installation was only half-finished, and they didn't have anyone who understood routing or network architectures sufficiently to sort out the unfinished setup. They'd spent weeks trying to fix it (not solid weeks, just weeks of back and forth) with the network guy who did the initial setup, but something just wasn't working, so they wanted someone to come on-site to fix it.

Cinemon setup is dirt simple for people who know how to set up a network on Unix boxes. You plug the private interfaces on your CMTS, DHCP server and Cinemon boxes into a switch. You give each of the 3 interfaces static IP addresses and you add a route to your DCHP-provided modem network range that uses the CMTS' private interface as the gateway. For normal system setups this means you just add the Cinemon server's second NIC to your back-end network.

The problem, as it turned out, was a simple instruction that was mis-understood. "They all have to go into the switch" (or something to that effect). The person following the instructions didn't realise that a separate switch was intended, so plugged the private interfaces into the public-network switch.

Now, you can set up Cinemon something like that way (with Cinemon talking over the "public" network to a gateway (e.g. a NAT-ing router) to the private network), or even with everything running on the same flat network. It's just not recommended for real-world networks, but these guys are using Cinemon for bench-testing hardware, so it would be reasonable. The problem is that when I was asked to comment, I was imagining that single-network situation, while the network tech was trying to describe the separate network situation. As a result we were instructing the client at cross-purposes and getting nowhere fast.

Anyway, guess the thing to take away from this is that we'll need to make more explicit documentation (i.e. stuff not intended for a network admin) for network setup. Maybe even include a pretty little graphic or two.