I've owed this summary to the list for a while...
The original routing question caused some confusion with the
answers I had recieved so a second message was sent out. Both
sets of questions are included below.
The jist of the problem was how do I (efficiently) allow
a primary and secondary router to operate automatically on my
network ?
The individual answers all of which were interesting and
informative are included below. Where an error was noted in an
answer I commented with ">>"
-----------------------------------------------------
THE SOLUTION:
The solution I chose was to let it rip... (sorry, I just
couldn't resist). ie. Let the routing daemon handle
finding the best route. No defaultrouter entry. I did
create an /etc/gateways file that contained the two
routes I was interested in as active routes. This was done
to insure the routes were in the table at boot time. After
boot the routers, both running rip, will send their routing info across
the net and routed will keep the tables up to date. This
will work fine, except for the notion of primary and secondary
routes. When IP searches the table it will always use the
route to my destination with either the shortest metric, or
if both are the same, then the first entry that matched. So I
cannot define one router as primary and one as secondary, but
it does not matter !!!
---------------------------------------------------------
THe ORIGINAL QUESTION
I have a question regarding the correct ? way to use the
/etc/defaultrouter file, /etc/gateways and routed ?
We have a customer who has a sparc connected to a network with
2 routers on the same ethernet (these routers connect a huge
routed network) but our sparc's only need to talk to 2 other
nets. They are both on line, but consider one to be a primary
and one to be a secondary. If I turn routed on in (quite mode)
a netstat -rn shows 100's of routes (most of which I'm not
interested in) If I use a /etc/defaultrouter file then
/etc/rc.local does not start routed so I only have a default
route and not the other router, (this is our current condition,
so when the customer pulled the primary for test we had no other
route -- customer was not happy -- )
1) Should I do "route add's" for the primary router and set
the default route to the secondary, not running routed ?
2) Should I just turn on routed -q and let rip handle it ?
(this creates a LARGE routing table)
3) Should I turn on routed -q and set up /etc/gateways
with active routes ?
SECOND SET OF QUESTIONS
A few answers said to make the PRIMARY route the defaultrouter,
but to my understanding the default route is the last match
that occurs from the routing table.
first a complete IP address match
second a network address match
third a default route.
If the above is true then the secondary should be the default
route and the primary route should have network address's
added to the table ? (any one know this for sure)
>> THIS IS TRUE, according to TCP/IP Illustrated Volume 1, The protocols
>> by Richard Stevens ( A great book)
If I turn routed off completely (saving table entries ....)
and just use "route add's") and /etc/defaultrouter (whis is really
also a route add) What process will update my router table when
my primarys goes down thus enabling IP to use the default route ?
in other words is it routed that receives the routers RIP
requests and updates the table or is there some other process
that handles this function ??
SPECIAL THANKS TO:
Barry Margolin
Don Lenamond
Steve_Kilbane
The MANY RESPONSES:
>1) Should I do "route add's" for the primary router and set
> the default route to the secondary, not running routed ?
I put the primary route in /etc/defaultrouter and other
routes in /etc/routes and modified /etc/rc.local to add
the routes using "route add" in my situation.
>> This solution won't work because there is no routing daemon
running to update the table(remember that having an /etc/defaultrouter file
causes rc.local to NOT run in.routed, also the default route is the last
route looked at by IP so the default should be the secondary.
-----------------------------
Use GDP or IRDP. See the FTP server at Cisco. There is IRDPD.C source
at Sun archive sites as well.
>> CAN'T COMMENT
-------------------------------
I> 1) Should I do "route add's" for the primary router and set
> the default route to the secondary, not running routed ?
well, if the customer only cares about the two nets, why have a
default? But yes, this is fine, and it's what I'd do.
> 2) Should I just turn on routed -q and let rip handle it ?
> (this creates a LARGE routing table)
Nope. Why waste that memory that could be used for other things?
> 3) Should I turn on routed -q and set up /etc/gateways
> with active routes ?
This won't do you any good, because you can't restrict the
information flow. Basically, you want your two routers to
just give you routes for the networks you're interested in,
and I don't think you can do that. If they're going to give you
any data at all, you'll get the rest of the routes they know about,
too. But you *do* want them to announce the routes, so that you
can spot when one of them goes down....
Hmm. May have sown more doubt than help, here...
>> THIS IS THE ONE THAT MADE ME SEND OUT THE SECOND SET OF QUESTIONS
(thanks to steve kilbane)
-----------------------------------
>1) Should I do "route add's" for the primary router and set
> the default route to the secondary, not running routed ?
This won't cause the fall-back to the secondary router that I think you
want. If the primary router goes down, the secondary will still be used to
get to networks that you didn't specify in the "route add" lines, but you
won't be able to get to those networks at all.
>2) Should I just turn on routed -q and let rip handle it ?
> (this creates a LARGE routing table)
>
>3) Should I turn on routed -q and set up /etc/gateways
> with active routes ?
If you want automatic re-routing, you need to run something like routed.
Method 3 seems like a good solution, as it allows you to initialize the
routes to use the primary router.
Note, however, that when the primary router goes down and everyone switches
to the secondary, they won't switch back to the primary automatically when
it comes back up. /etc/gateways just specifies the initial routing table,
it doesn't create a preference.
If your routers provide a way to adjust the routing metric, you can arrange
for the primary router to send out a lower metric than the secondary. Then
the primary will always be preferred when it's up. In this case, you
shouldn't need to initialize things with /etc/gateways.
(Thanks to Barry Margolin )
---------------------------------------------------------
>| 3) Should I turn on routed -q and set up /etc/gateways
>| with active routes ?
3rd one is the best way I think. Because you need the gateways automatically
update your machine's routing table when there is a change on other nets.
Also you ignore the routing updates from all other routers. This prevents
your routing table get bigger unwantedly.
---------------------------------------
If your SPARC only needs to talk to the 2 or 3 specified networks, and
nobody else in the world, then creating 2 or 3 static routes is your
simplies solution, and impacts the SPARC performance the least. Keep
in mind though that without in.routed running, you will NOT have any
dynamic routing at the SPARC. It will know of only the routes you
statically specify. End of story. Each time you need to get to
a new network outside of your static routes, YOU become the routing
protocol as you add each new route.
Using the /etc/defaultrouter method won't supply the solution because
you need to specify two routers...this method only defines one router.
Running in.routed will allow provision for both routers on the
same network, and will automatically find the secondary router if the
primary were to fail (after the polling period for RIP is reached). It
will also find any new routes you need dynamically by polling the routers
it knows for the best path.
Unfortunately, RIP as a routing protocol is limited in its metric for
least cost (number of hops only), and creates lots of overhead on the
network. If the SPARC has sufficient resources (memory, cpu) to
allow RIP to run, leave it running.
-------------------------------------
try 'in.routed -S'
>> THIS IS INCORRECT, BECAUSE THIS WOULD CAUSE THE SPARC TO SEND ITS ROUTING
TABLE,FLOODING THE NETWORK.
--------------------------
If the routes are always static to the two nets you wish to
communicate with, then it will be much more efficient to
have the routes added manually. Put the route add commands
into your /etc/rc.local or /etc/init.d/? file and leave
routed off.
If you want some more flexibility to recieve updates from
the routers connection you to the two networks, then grab
a copy of "gated" (a routed replacement), where you can
define which routers are "trusted" and will therefore have
updates accepted from. You can then prune out the other
route information. This of course will take more CPU time
on your machines than the static route solution.
>> I have started to look at gated
-------------------------------------------
>
> If I don't run in.routed (using only static table entries)
> Then I suppose when one of my links goes down I will never detect
> this condition and update my routing table accordingly ???
> Or, is there somthing I'm still missing in this picture ???
You nailed the right answer. The whole idea around dynamic routing
is that routers learn each others routes automatically. If a known
route goes down, sooner or later the routers all learn a way, if
possible to get packets to the destination of choice.
Herein lies a dilema. If dynamic routing is turned on, system
resources are going to be used, ie. system memory for route tables,
cpu cycles as the ethernet interface listens, learns of new or
changed routes, and if more than a single interface is installed
within the SPARC (and IP packet forwarding is enabled), the
SPARC actually routes between interfaces. SPARC's do an okay job
at routing in small networks, but for any large network or multi
protocol network, an external router is preferred or needed.
In your case, I still think running in.routed an optimum solution
for the shear fact of needing a primary and backup router available
if loss of service of the primary should happen. Be aware it will
not be an instantaneous switch as RIP updates are every 30 to 60
seconds, depending on who's routing protocol you use.
I also found quite a few bug reports within SunSolve relating to RIP.
Some are fairly substantial in having problems. If you have
access to this resource, look up on the keyword "RIP" and see if
you can get any patch id's for some of the bugs. I found
bug's relating to SunOS 4.1.3 back to 8/93. Perhaps the 4.1.3_U1
or later implementations will be better. Of course, Solaris 2.4
is even better because Sun is now using both in.routed and
in.rdisc for routing...the later being much less broadcast intensive
on the network.
Lastly, keep up hope...perhaps one day a new "RIP" will come along
that everyone will adopt. Seems these days, that's not happening!
The new supposed routing protocol of choice, OSPF, is not even the
same AMONG vendors. (try getting a Cicso and Proteon to speak to each
other in OSPF...it can be done, but not easily). Cisco's new claim
to fame, EIGRP (Extended Inter Gateway Routing Protocol) is their
solution to variable length subnetting, but it is still a derivative
of distance-vector route protocol similar to RIP. (I need to read up
on this one...)
---------------
Routed (or another routing daemon like gated) normally updates the table.
However, the table could also get updated via ICMP redirects -- if the
default router isn't the closest one to the destination, it will send a
redirect to the Sun. This will create "complete IP address" entries in the
routing table. Routes that result from these are marked with "D" in the
"netstat -r" output. Note that these routes won't ever time out, so if
that router goes down you'll lose connectivity to those machines.
If you want automatic fallback, running routed is probably the best way.
-----------------------------
Thanks to all
Joe Welfeld
=====================================================
Joe Welfeld Data Switch Corporation
Email:jwelfeld@dasw.com 1 Enterprise Dr.
Systems Engineer Shelton, CT. 06484
203.925.7548 Fax:203.929.8494
====================================================
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:15 CDT