Tunneling Linux Routers
This chapter is from the book
This chapter is from the book
This chapter is from the book
Cesium and xenon are the routers that didn't know they were going to be routers. They were yanked out of their retirement jobs as door stops and dust collectors and impressed into service to save us large sums of money. The basic story is that my group is located in a work center amidst service reps and other folks who need, at best, a single network connection. So every cube is wired with a single network drop, and (gasp) it's all token ring. The group was fortunate enough to be allocated some Sun Ultra5 workstations by the budget gods, but the systems didn't include token ring cards (over a thousand-dollar add-on if purchased directly from Sun). There are a few third-party token ring cards that will operate under Solaris, but we still only had one network drop per cube. Wiring costs, if you've never had to pay them or budget for them, are astronomical. You would think that wireless LAN technologies like 802.11b would price themselves out of the market when compared to the cost and performance of CAT5, but wireless technologies suddenly become attractive when you're faced with funding a crew of electricians pulling cable for a week. Furthermore, we didn't want to pour company money into more token ring drops on the principle of the thing. Well, a Sun workstation without a network connection is only fun for about a day, after which it becomes a very expensive screensaver platform. All Sun systems come with Ethernet ports, so we chipped in on a 10Base-T hub and built our own network segment between the machines, but we were geographically limited to a single row of cubes—you cannot have CAT5 cables running across walkways in work centers.
Although we were short on network connections, we had literally stacks of old 486 and older Pentium boxes, and cartons full of token ring cards. (At the risk of dating myself, a 90MHz Pentium was once a wickedly fast computer—probably at about the same time that token ring was a strategic technology.) Enter cesium to tie the rowA segment to the token ring, and not long afterward, xenon for rowB, and so on. Each token ring gateway, for lack of a better term, needed a token ring card to tie to the main network and an Ethernet card for the local workstation segment. Once we were physically tied to both networks, they had to talk to each other. And sometimes, just sometimes, you're not the network administrator. In this instance, it meant that we were not free to request from the local network administrator that a subnet from the local address space be routing to our token ring gateway so that we could route it to our Ethernet-based workstations. In the general case, you may find yourself needing to construct (sometimes elaborate) network topologies solely because you are not in a situation to request a simple change from the network powers that be.
Fortunately, the networking stack in Linux provides several facilities that make these sorts of configurations possible. (I guess I wasn't alone in needing this sort of configuration.) In this chapter we'll briefly revisit masquerading and talk about how we might let a few things from the outside in. We'll also talk about tunnelling, which can be used to connect two or more networks separated by an intervening network with no knowledge of/support for those networks. As part of the discussion on tunnelling we'll introduce iproute2, a powerful replacement for the traditional network-configuration commands like ifconfig and route. Then, we're going to put it all together to build secure tunnels, also known as VPNs, using FreeS/WAN, an IPsec implementation for Linux. Finally, we'll sink our teeth into some IPv6.
6.1 Linux and Token Ring
In terms of networking hardware, cesium and xenon don't look much different from our basic Ethernet router, silicon, save that they have a token ring card in place of the second Ethernet adapter. There's a long story about not being able to boot Compaq Deskpro XL90s directly into Linux because of some craziness about a DOS-based device driver that has to be loaded to map the BIOS into memory. Instead of going into that, I'll summarize by saying that the best way to boot one of these beasts is to boot oN of a DOS diskette, load the silly device driver, and then use syslinux to load the Linux kernel from that same floppy and boot the box into Linux. And find a HOWTO There is another equally long story about getting a PCI-based Madge token ring card running under Linux. At the time, the drivers were not part of the upstream kernel, and I had another relatively discouraging experience with vendor-supplied drivers. Not that I'm ungrateful that Madge oNers Linux support—that's the card I had on hand—and I was able to get things running. (And token ring cards remain expensive. I suppose they never reached critical mass in the marketplace.) But things just seem to take longer with vendor-supplied drivers. The precompiled binary versions are invariably for a kernel other than the one you need to run (and there always seems to be a good reason for that), and the source kits can suNer from odd build dependencies (in this case newt) or general libc or kernel version touchiness. I'll take a driver from the upstream kernel over a vendor driver any day.
Since this is a networking book, token ring itself deserves a little attention. Although much maligned—sysadmins who join my group always react with You're running what?—token ring is a little like the Rodney Dangerfield of LAN link-layer protocols. The protocol is actually much like FDDI, both in its token passing (only the person holding the token is permitted to speak, or transmit) and in its stability during peak-load situations. Token ring has the ability to weather very high load without any nasty drops in throughput as on a bridged Ethernet segment, and without expensive concentrators like Ethernet switches. If you're interested in learning more about the protocol, try http://www.networkuptime.com/faqs/token-ring/, which is a collection of questions and answers from the comp.dcom.lans.token-ring Usenet news-group. You can also go straight to the source and try http://www.8025.org/, but it's a tad dry for my tastes.
If you do happen to be running token ring on Linux, you can expect the same stability from it that you do with Ethernet. You may notice that a few tools lag behind their Ethernet counterparts. For example, older versions of tcpdump won't decode the packets on the wire for you, so you're stuck with a timestamp plus station addresses, flags, and then raw packet data as shown here. Newer versions work as you'd expect. Here is what the old output looks like:
cesium:~$ tcpdump -n -i tr0
22:21:30.643295 0:0:90:0:5a:7d 10:40:c0:0:0:1 609e 352:
c220 aaaa 0300 0000 0800 4510 0148 792d
4000 4006 e5db ab88 23f0 ab88 5f96 0016
03ec 77f0 03e8 7847 968f 8018 7d78 94ec
0000 0101 080a
22:21:30.643295 60:9e:0:6:7c:97 10:40:10:0:5a:7d 7ac1 74:
aaaa 0300 0000 0800 4510 0034 e54e 4000
3e06 7cce ab88 5f96 ab88 23f0 03ec 0016
7847 968f 77f0 03e8 8010 7c70 9bb2 0000
0101 080a 99a9