UNIX admin writes: > The catch is that the ADSL "modem" only has one EtherNet port, so only one > system can be connected to the Internet. Well, no problem, IPFilter to the > rescue!
Have you tried connecting a hub to that Ethernet port? That'd have to be an extraordinarily lame device if it doesn't support more than one client at a time. If so, I'd probably chuck it out the nearest window rather than fooling with an extra layer of NAT. > By NATting all LAN and DMZ packets to the external interface of the > FW (also a non-routable IP address on the same subnet as the > "modem"), I trick the "modem" into thinking that there is only one > host connected, when there is in fact an entire server farm and two > DMZs behind that one IP address. But it's still wasteful and > overhead to perform the NAT twice for every packet coming in or out. Given the relatively low speeds involved here, I wouldn't worry terribly about the overhead. I'd worry more about the functionality of the link. As long as it's actually working right, more power to you. > > At the lowest level, DSL links essentially just > > provide a synchronous > > bidirectional (full duplex) communications path. In > > order to put > > packets on there, you need some sort of framing -- > > that can be HDLC or > > AAL-5 plus ATM. > > If I understood correctly, what they're doing is is transporting TCP/IP over > ATM. Not exactly. They're carrying multiple layers of encapsulation. As long as you put a few "..." in that sentence, it's right. > > To use routers, you'd have the head-end termination > > break out the bit > > stream (as is done today), but instead of running > > that into an ATM > > switch, just run it into an access router. The > > router can then run > > HDLC over the link, and PPP works fine on that. > > But could they have run EtherNet all the way, or is the copper line the > problem for EtherNet? I mean the last mile. And once at the CO, just normal > EtherNet routers and fiber back to the backbone? I don't see any particular reason they could not use Ethernet, but it's a completely different protocol, with a completely different set of engineering issues -- from wiring, to crosstalk, to EMI, and so on. The head-end is an important concern there. The 'ideal' Ethernet deployment would have routers at each street corner. DSL doesn't always look like that; instead, since it is designed to reuse existing copper from telephone lines, it has to deal with near-end crosstalk where all these wires are aggregated into a CO. This is also the reason for the 'A' in ADSL. The low-level DSL interface constrains the sort of solutions that make sense here. > > be done based on PPP plus backend AAA. The ATM > > mechanism gives > > you a way to bill separately for each remote > > endpoint, even if > > they're on a single DSL line (should you choose to > > do so). > > Yes, but why would we need to meter? Yes, there are still fascist-like telcos > out there that measure your monthly traffic, but I predict that that > billing/business model has no future. In the future all ADSL or SDSL or > whichever technology replaces it will be flat rate. If we speculate that my > assumption is true, what would need to be metered? I can't really imagine what problem or constraint metering solves; I'm merely noting that it's a concern for some providers. I usually assume that regulatory and business issues just exist outside of a plane in which engineering takes place. It's not really all that worthwhile (at least to me) to try to divine some deeper meaning in them. -- James Carlson, KISS Network <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ opensolaris-discuss mailing list [email protected]
