Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!boulder!daemon
From: ccci!tcs@uunet.UU.NET (Terry Slattery)
Newsgroups: comp.dcom.sys.cisco
Subject: Re: Routing query
Message-ID: <34392@boulder.Colorado.EDU>
Date: 22 Apr 91 13:30:40 GMT
Sender: daemon@boulder.Colorado.EDU
Lines: 101

Peter,

Redrawing your network to reflect the new configuration (note the
transposition of QLD and ACT to make the drawing simpler):

                             2Mpbs
                       ACT---------+
                        |          |
                        |         NSW
                        |2Mbps     |
                    QLD |          |.048Mbps
                      \ | ---------+
                       \|/
          WA -----------N---TAS   
                       /|       P----> 128K satellite to USA
                      / |       |
                     / -+---+---+-
                   SA       |
                           VIC


As I understand it, you want to have ACT and NSW use the ACT->N path for
normal operation.  ACT should switch to the ACT->NSW->N path if the ACT->N
path fails and NSW should use the NSW->N path if either ACT->N or NSW->ACT
path fails.

>HOW DO WE SET UP OUR ROUTING TO DO DYNAMIC FAILOVER TO THE 48K IF ONE
>OF THE 2Mb LINKS DIES ?
>
> My current thinking goes as follows:
>
>A) Stick with RIP. We can only do this if there is some method of
>artificially increasing the hop count of routes sent from NSW to
>the national hub over the 48K line. The "offset-list" parameter only
>allows you to fiddle routing metrics on a per network, rather than 
>per interface, basis.
>
>IS THIS TRUE ? CAN WHAT I WANT BE DONE ?

Your problem is that you want to make routing decisions based on link
bandwidth and the protocol you're using uses hop count as its metric.
Something outside RIP must be done to add the information about path
bandwidth.

You could specify a floating static route to install the backup path with an
administrative distance which is normally overriden by RIP updates from the
routers along the 2Mbps path.  If the RIP info is lost, then the path is
presumed down and you use the backup static route.  This allows you to stay
with RIP and all of your current configuration.

>B) Fire up IGRP to be able to dynamically detect the failure of one of
>the 2Mb lines. NSW and ACT routes will have to be distributed between all
>three routers but since most of them have are learnt via RIP, to
>redistribute them using IGRP we will have to use a "default-metric"
>for them all.
>
>DOES THIS MEAN THAT ALL RIP ROUTES REDISTRIBUTED BY IGRP WILL HAVE THE
>SAME METRIC REGARDLESS OF WHICH INTERFACE THEY GO OUT OVER ?

Yes, all RIP routes will have the same metric if you redistribute them with
IGRP.  This is typically not a problem since the information will disappear
if the route is marked down.

You could do some weird things using different IGRP Autonomous Systems,
selecting which routes each IGRP AS includes, and have each redistribute via
RIP.  This is probably much more complex than you want.

>(which, of course, negates the reason why we were going to run RIP in
>the first place :-).
>
>I guess the another option would be to run IGRP throughout AARNet, but
>that's a pretty big change just for a new link! 

Why does that negate your reason for running RIP?  You're using default
routes for all out-of-area routes, so all you have is reachability
information (no metric).

Most places run IGRP in their routers and redistribute the information using
RIP.  The IGRP routers broadcast RIP default routes tell the stub networks of
the backbone.  When you're running IGRP, redistributing the IGRP information
into RIP, and need to import some dynamic routes via RIP, you have to
install filters to select only the RIP routes you are interested in
propagating.  (This presumes that the equipment sourcing the RIP routes
doesn't do split-horizon.)

>Would this work ?
>
>router igrp 1221
>redistribute static
>default-network 132.160.0.0
>!
>ip route 132.160.0.0 139.130.x.y
>
>ie. advertise 132.160 via IGRP, marked as an "exterior route" but don't
>rely on it being passed dynamically to us from the Proteon.

That looks fine to me.

>Peter Elford,                           	e-mail: P.Elford@aarnet.edu.au

	-tcs