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
This information is reprinted through kind permission of the author,
Michael Galassi
Tony Sanders
"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:
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
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
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).
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
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.
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.
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.
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.
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
+ 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.
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.
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
---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).
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.
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).
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.
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.
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.
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.
Ifconfig/Basic Test
To configure the rn0 interface using ifconfig, you'll need the following Internet
connection parameters:
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).
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.