20.0 Conclusion

We're in an exciting world here, the emerging world of global communications some call "Cyberspace". Those of us who work to shape this world in our own image are called Internet Service Providers. It's an awesome responsibility. Let's try to make it work.

I hope you have found the information in this FAQ to be helpful and of interest. However, to make this document truly useful, I need your contributions, which will be credited as requested.

David Dennis david@amazing.com dhd@netcom.com

APPENDIX A: Simulating a Router

Kevin Smith was kind enough to forward a message he saw on USENET about using BSDI as a router. I hope this will help those who have this problem in the future.

This information is reprinted through kind permission of the author, Michael Galassi . I dropped him a follow-up line asking permission to reprint, and asking for a price for the RISCom/N1. He tells me it's "under $ 500 but I don't remember how much." You can contact SDL Communications at (508) 238-4490 for more information and current pricing.

Tony Sanders offers the following as an update:

"These days you will probably be getting a RISCom/N2 card from SDL, they come in single- and dual-port versions (very nice for setting up a hub). You'll need a driver from BSDI for it as it has a different interface from the N1 card (just ask support@bsdi.com for the N2 driver). Everything else is pretty much the same."

This is the last item in the FAQ due to its incredible length (over 400 lines). If you are not interested in this specific subject, you can stop reading now.

From: nerd@percy.rain.com (Michael Galassi) Newsgroups: info.bsdi.users Subject: RISCom/N1 summary of experience Date: 18 Jul 94 22:13:34 GMT Organization: University of Illinois at Urbana Lines: 404 Approved: Usenet@ux1.cso.uiuc.edu Message-ID: Reply-To: nerd@percy.rain.com NNTP-Posting-Host: ux1.cso.uiuc.edu Originator: daemon@ux1.cso.uiuc.edu

Hi,

A week or so ago I requested tips & experience of the list to help me in an impending conversion from a MorningStar Express to a BSDI box containing a RISCom/N1. I've received several requests for this info and two people have provided me with some help. Additionaly, when I ran into hardware problems the people at BSDI were as usual quick to respond, very competent, and nice to deal with (they didn't even sneer at me for not recognizing my hardware problem for what it was). Great bunch.

The end result is quite nice, performance is great, the interface to the router is what I'm used to in my normal syadmin chores rather than some vendor's idea of what is best, and the machine is truly flexible, I want more ports I go to any PC store, buy the board, build the kernel and I'm off and running.

For starters, the responses I received pointed me at a document available on world.std.com (now ftp.std.com?), I failed to locate the doc there but both people were kind enough to provide me with a copy of this document. I've attached a copy of it at the end of this message.

First off, the pitfalls I ran into. o My motherboard (noname vlb 486/33) which appeared to work nicely in an enviroment including 3 ethernets and a DigiBoard routing SLIP did not work well with the RISCom/N1, the symptoms were that within no more than an hour of starting the rn0 interface would lock up, all else seemed OK. o The weather out there was nice and I would have rather have been on my motorcycle. o getting the IRQs, I/O addresses, and memory mappings right for all the boards was hellish.

The solutions involved replacing the motherboard, buying a new bike the next day as a consolation prize, and taking very carefull notes *ON A MACHINE THAT DOES NOT RELY ON THE ROUTER*.

The basic steps involved:

Create a config file rn0 defined. CAREFULLY pick IRQs, memory & I/O locations that don't clash and update your config file. At this point you need to know if your IP provider supports CISCO's HDLC or PPP, the later is more likely. Add a line that reads "options CISCO_HDLC" or "options PPP" as needed. Build your new kernel and install it. At this stage DON"T change any files in /etc such as netstart, rc.local, hosts, or DNS configuration, you'll get that later.

Configure the switches on your N1 to match what you've set in the kernel

Shut down your machine and put the N1 in it.

Boot up ms-dog and run the diagnostics for the N1, the program is called n1.exe and is in \dos on the floppy you got with your N1. There is aparently more than one version of this program for mine did not match the documentation that came with the N1. The program is close enough to "self documenting" that you should be able to wing it. One pot-hole I fell into, I configured my N1 for IRQ 10, same for my kernel, but, the diagnostics won't let you use that interupt. Since I wanted my board to run with the same config as the diagnostics had tested I changed my config a bit. I would guess the longer you run the diagnostics the better, I lost patience at about 30 minutes .

When you are bored with watching the diagnostics, power down and attach the cable from the db25 on your N1 to whatever DSU you have, this should cause some LED activity, diferent DSUs will work diferently. Punch reset and watch the boot message carefully, you should see a line looking somewhat like: rn0 at isa0 iobase 0x220 irq 3 maddr 0xe0000-0xeffff Obviously your numbers may be diferent from mine.

If you don't see this run strings -a /bsd | grep "rn%d", if you get no output you messed up building the kernel. If you do get output cd to your build directory and look at ioconf.c, make shure the numbers on the line that ends in /* rn0 */ match what you gave in your configuration, if they don't rerun config, redo your make depend & your make, reboot and try again. If they do match they you have a hardware conflict or an incorrectly configured board. Fix and repeat as needed.

Once you are up in multiuser mode log in as root, and manualy ifconfig your board with the local and remote addresses, netmask and link flag, I use: ifconfig rn0 inet 199.2.108.234 199.2.108.233 netmask 255.255.255.240 link0 that is, the local side is at 234, the remote end is at 233, the netmask is 0xfffffff0. The link0 means I run PPP on this link, its absence would indicate CISCO's variant of HDLC framing.

You should now be able to ping the remote end of your link, in my case "ping 199.2.108.233", if this is the case, you can add a line identical to the one you typed above to your /etc/netstart and you are done!

This leavs a *small* matter of routing. If you are a leaf node you can get away with "route add default ", otherwise you will need to configure gated to do the "right thing", this is left as an excercise for the reader.

Hope this has helped some, writing it down certainly helped me see what I had done and realize what I'll do diferently next time.

If you run into problems doing any of this, drop me a line, I'll be happy to review config files and other similar things to help you out.

-michael

---cut here---

Using BSDI as an Internet Router

This document describes the basic procedure for using the SDL N1 board in a BSDI machine to implement Internet routing functionality. This includes useful general information such as N1 setup which should be applicable in many proprietary (non-Internet) network connections.

Introduction

The good news is that getting the N1 to work is almost as simple as plug'n play. Additionally, my own tests and from talking to BSDI folks, confirm that even a 20mhz 386 BSDI machine has more enough cpu power to move lotta packets; I get better consistent thruput using BSDI/N1 than I did using a NAT router (and no longer have to deal with a number of connection killing bugs that plague the NAT router).

Note that typically when you dedicate a machine to something as important as routing (and other site services such as mail forwarding, POP account, DNS, proxy ftp) don't give people login shell accounts on that machine. Also, for security reasons it might be a good idea to chmod 400 on the /dev/bpf* devices (or disable access to those devices completely once you've debugged the setup).

The Environment

The Internet connection is through a 56kbs leased line (PacBell ADN - California) terminated using a Dowty DCP3080 CSU/DSU. The N1 board connects to the CSU/DSU throught a V.35 interface using the cable supplied by SDL. The host with the N1 board then gateways to other machines connected via ethernet.

Installing The N1

An overview of the steps involved:

o Determine available base I/O, interrupt, dual port ram of your bsdi machine

o Figure out if you have to do anything special about caching

o Test the N1 to verify setup

o Build a new kernel

o Boot new kernel; basic N1 test

Setting base I/O, etc.

The default BSDI N1 setup requires that the board's base I/O be set to 0x220, uses interrupt 5, and assumes dual-port usage at 0xe0000; these are very reasonable defaults but check your config to see if they will work for you. Note that since the N1 is a 16-bit device, it requires a 128kb segment of dual-port ram (see N1 manual).

To check for suitability of preceding defaults, execute the 'dmesg' command to display your machines config. The dmesg command will list all devices base I/O (iobase), interrupts (irq), and dual-port RAM use (maddr).

If there are no conflicts, set the boards S1 switch to use base I/O 0x0220 and interrupt 5. The maddr range is set in the BSDI kernel config (as described shortly). Install the board in selected machine.

Setting up for Caching

Now determine if the machine with the N1 uses an external cache; if it does, determince if it's a write-thru or write-back. Check your motherboard manual.

Higher quality and most newer motherboards use the write-back cache; with this type of cache you do NOT have to configure the dual-port RAM area as non-cachable.

Older and cheaper mother boards use the write-thru cache; with this type of cache you MUST configure the N1's dual port range as non-cachable. Depending on other boards you have installed (ethernet), it is possible to run out of non-cachable regions in which case you'll have to turn off the caching.

Some motherboards support both type of cache; determine which is enabled on your board and act as needed.

Testing the N1

Boot the machine with DOS and run the N1.EXE test program (provided by SDL). This program will verify basic functionality such as base I/O settings and interrupt. The most important thing this program will do is verify that the desirable dual port ram range works on your machine.

The default 0xe0000 address should work fine with most newer MBs using write-back cache; however, older boards might have problems. For example, the machine I installed my N1 in would only pass the dma test at address range 0xa0000.

Address range 0xa0000 is also used by vga driver; since I don't run X/have a vga card on this machine, when I rebuilt the kernel, I deleted the vga driver. If you use an older board, be aware of special situations like this.

Bottom line is, the N1 must pass the dma test at the memory range you plan on using. If it doesn't pass - don't go any further; things will not work.

Building the Kernel

In configuring the kernel for the N1 you should disable any devices you don't need since adding the rn0 device could result in a kernel that breaks certain mem size limits. When you enable the rn0 device, be sure to also change (if needed) its port and iomem parameters.

In addition to enabling the rn0 device, be sure you also do the following:

o Enable the network option GATEWAY (this enables IP forwarding as needed by an Internet gateway machine).

o Talk to your Internet service provider and find out what type of protocol their routers expect. Almost 100% certain that they will say PPP. If so, enable the PPP option; in this case you do NOT need the CISCO_HDLC option (use this option only if you need it).

Follow the BSDI instructions and build a new kernel with the rn0 device enabled.

Boot New Kernel; Basic Testing

Prior to booting with the new kernel, you should connect the N1 to the termination equipment you plan on using, and turn on that termination equipment.

Reboot the machine; you should see rn0 in the device list. If you miss it, use dmesg to verify that the kernel found the N1 at the desired base I/O, interrupt, and maddr range.

Once the machine reboots, the CSU/DSU RX data light should be on. Now use ifconfig to enable the rn0 interface. Note that if the N1 isn't connected to line termination device (CSU/DSU), or if cable is bad/incorrect, you'll get "rn0 timeout" messages displayed on the console.

Use the following basic ifconfig line to enable the interface:

ifconfig rn0 inet Host_IP_Address RemotePort_IP_address

At this point the TX data light on the CSU/DSU should come on. If it does, basic functionality is OK, but don't try much else until you read the following sections. At this point you can use two IP addrs from your assigned block, however, the CSU/DSU should NOT be connected to the leased line.

I used a Dowty DCP3080 CSU/DSU; the only setting I had to change was to enable the V.35 interface (instead of the serial interface). Note that in making this type of change, you'll probably have to power cycle/reset the CSU/DSU.

Note that the rn0 driver doesn't seem to support DTR, so the CSU/DSU DTR light doesn't come on (and neither the DSR light if CSU/DSU configed so that DSR follows DTR). This is not a problem; things will work just fine (at least with my equipment).

Setting Up BSDI as Router =========================

The basics steps are as follows:

o configure the rn0 interface using ifconfig o test connection to rn0 interface o probably want to get gated as IP router daemon o set default route on other hosts

Ifconfig/Basic Test

To configure the rn0 interface using ifconfig, you'll need the following Internet connection parameters:

+ the IP address for the rn0 interface

+ the IP address of the interface at the service provider's end

+ the netmask and broadcast values for the rn0 interface

The IP addresses, netmask, and broadcast values you get from the Internet service provider, or if you have an existing Internet connection, you can login to your site's router (if you have the passwords) and dump the config data. If you have no idea what this means, get the info from your Internet provider.

The above parameter's are crucial to proper connection function. Don't try anything until you have them; things will not work.

For example, my ifconfig (in /etc/netstart) looks as follows (NOTE link0!):

ifconfig rn0 inet 131.119.67.134 131.119.67.133 link0 \ netmask 255.255.255.252

The first IP address is the IP address of the rn0 interface (mentioned as $hostname in template form in /etc/netstart); the second IP address is the remote port (of a Cisco router in this case); in /etc/netstart rn0 template this is the __remotehost__. Though it might be nice to use names instead of IP addrs, you'll probably have trouble with names (known bsdi isssue).

If the connection is PPP, you MUST specify the "link0" interface option! If the connection is CISCO_HDLC, you don't need link0.

Netmask is per service provider instructions; broadcast uses default 131.119.255.255 which is fine, again per service provider info (see ifconfig man page).

Before editing /etc/netstart, enter the ifconfig command manually. Verify TX data light goes on in the CSU/DSU. Don't be to anxious; if routed or other router daemon is running, kill them before entering the ifconfig command and verify that your routing table is minimal (netstat -r or -nr).

Now create a default route (route add default IP_addr); use the IP address of the machine with the N1.

Once the default route is created, you should have connectivity. Test DNS resolution, etc. Things should work fine. If not, use tcpdump to view activity (tcpdump -i rn0). Note that from this point on exactly what happens depends a lot on you Internet service provider. At a minimum I would hope that tcpdump would show RIP requests, and maybe SNMP requests. This would indicate that your connection is functioning and accepting packets. Outbound packets can be verified with something as simple as a ping; this will show that IP forwarding is working.

See next section for some Internet related details. If things worked, you can edit your /etc/netstart file and add the ifconfig line. However, at this point, you should comment out any 'route add default' command; see next section.

Router Software

To turn the BSDI/N1 machine into a router, you probably need router software. Check with your service provider. They might be willing to set static routes for your site (though don't count on it).

If they require true router capability, find out what protocal they want to use. BSDI comes equiped with routed. Routed supports RIP; a very common PPP link router protocol. However, I was not able to get routed to work for my site, and at the suggestion of my service provider, I was told to use gated.

There's good and bad news about gated. The bad news is that it don't come with BSDI 1.0; the good news is that it's easy to get and compiles totally clean and simple. Also basic config is trivial, and gated supports a wealth of router protocols.

I initially tried routed. The problem was that routed would not respond to RIP requests from my service providers router. Hence, packets from my site would go out, but responses never came back. Specifically, packets originating on the gateway machine (the machine with the N1) would have the correct source IP address and everything worked fine from that machine. The problem was with the other hosts using the gateway machine as the default route. Other hosts packets went out; replies never made it back. Fun to verify this using traceroute and tcpdump.

My service provider would not help with routed; they are familar with gated and basically said "use it".

Here's my most favorable experience with gated:

1. ftp to gated.cornell.edu; cd pub/gated 2. get gated-R3_0_2.tar.Z (make sure set transfer mode to bin!) 3. Uncompress/untar; read README; follow instructions to build 4. Use the minimal gated.conf file that says "rip yes ;" 5. Install gated.conf in /etc; gated binary in /sbin (NOTE: as built gated is HUGE; might not fit in /sbin on root partition. Do a 'strip gated' to remove symbolic info and reduce to reasonable size.) 6. Edit /etc/netstart to say NO to routed 7. Edit /etc/rc to enable gated

Once I rebooted with gated; everything worked!

NOTE: Gated README file cautions that for RIP to work, kernel must support UDP checksums. By default, the BSDI 1.0 kernel does support UDP checksums; its all set to work.

To finish up, set the default route on all other hosts to point to the gateway machine. Note that if you're switching from a router to a bsdi machine, you could use the IP addr of the router's ethernet interface as the IP address of the bsdi machine. I did not this this so I coauld bounce back and forth between router connection and bsdi connection until things were debugged.

Summary

Hopefully the basic steps in this document are useful, however they are not a susbstitute for common sense. Be creative, especially in initial stage. For example, as long as CSU/DSU not connected to Internet line, and ifconfig with junk IP addrs could show that things are basically functional by causing the TX data light to go on.

Also keep in mind a cooperative Internet service provider is needed. Good luck in this sense.

-michael

--

Michael Galassi nerd@percy.rain.com Next section: l Galassi nerd@percy.rain.com