As explained on this page, when a CopperEdge DSLAM is used with an Ethernet uplink rather than DS3, a misdesign on CM's part makes it impossible to serve out true routed DSL circuits, only bridged. This misfeature has been problematic for our lab testing: because the rest of our Open WAN Connectivity Project has been focused primarily on routed circuits, we have better test means for the routed configuration: for example, we have an IP router application on our Hack-o-Rocket platform, but not a bridged counterpart, and now that we have finally built our OSDCU and are beginning to test it with classic synchronous serial WAN routers, the routed circuit configuration is certainly much easier to test first.

Serving out routed DSL circuits from a CopperEdge requires using the cross-connect netmodel rather than IP, and that in turn requires using a non-Ethernet WAN uplink like DS1 or DS3. Our ex-NorthPoint DSLAM came with a DS3/ATM WAN card, but we couldn't make any real use of it as equipment that can serve out DS3/ATM isn't exactly cheap. However, thanks to the quad T1 WAN module kindly donated by David Jones of Routerspot we've been able to put together a solution that wouldn't be viable for a real ISP, but works for our experiments in the lab.

The trick requires having a CopperEdge DSLAM with two identical WAN ports such that you can run a pigtail cable from one to the other. One can use a CE200 with two DS3/ATM cards, two DS3/FR cards or a lower-speed WAN card like quad T1 that has multiple ports on one module. In our case the WAN card is quad T1 and we have a wire contraption consisting of two RJ45 plugs and two scraps of cross-connect wire running from one port on the card to another just below.

When one takes a WAN (DS1 or DS3) PVC as opposed to an xDSL port and sets it up for the IP netmodel, it is presented to the IP stack as an unnumbered point-to-point interface with a traditional routed encapsulation, not bridged Ethernet. So here's what we do:

• We set up virtual circuits on one of the T1 ports connected by our wire hack (call it 1.4.1) and put them into NetModel=IP. The DSLAM's IP router function can now pass IP datagrams between these p-to-p interfaces and the Ethernet port in the standard manner.
• We take the other T1 port (call it 1.4.2) and set up virtual circuits on it with the same VC (DLCI) numbers as on 1.4.1.
• We set up our SDSL ports with the cross-connect netmodel and point the DestPii at the virtual circuits on 1.4.2.

Packets now take the following path:

1. An IP datagram arrives via Ethernet and is handled by the DSLAM's IP router function. It goes through the routing table and dispatches the datagram to one of the PVCs on 1.4.1.
2. The packet leaves the DSLAM chassis via the physical jack corresponding to PII 1.4.1, encapsulated in the routed RFC 1490 format in DS1 electrical signal form. It travels a few centimeters outside the chassis and comes right back in through the PII 1.4.2 jack right below.
3. When the packet comes back in on 1.4.2, the DSLAM has no idea that it's the same one it just sent out on 1.4.1. Unlike 1.4.1, the VCs on 1.4.2 are configured for the cross-connect netmodel, so the IP stack doesn't get involved this time.
4. The T1 WAN module is HDLC-based and so is CM SDSL, hence in the cross-connect netmodel the packets pass right through without any alteration.
5. Voila! The packet in the routed RFC 1490 encapsulation goes out on the SDSL pair!

There is only one little problem with this solution: the combined bandwidth of all DSL circuits served in this manner has to go through that DS1 interface at 1.536 Mbps. Obviously not usable in a real operational setting with real customers, but OK for experiments in the lab. On the other hand, if one were to do a similar hack using two DS3 WAN modules (filling both WAN slots in the CE200 chassis) instead of our quad T1 module, the bottleneck goes up to 45 Mbps — not bad, perhaps viable in a real operational setting if one doesn't mind the awkwardness.

Back to our Copper Mountain pages