NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/dcom/sys/cisco/1563

Text File | 1992-11-07 | 7.9 KB | 154 lines

Newsgroups: comp.dcom.sys.cisco
Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!megadata!andrew
From: [e-mail] (Andrew McRae)
Subject: Re: re: advertising static routes
Message-ID: <[e-mail]>
Originator: andrew@noah
Sender: [e-mail]
Organization: Megadata P/L, North Ryde, Sydney, Aust.
References: <[e-mail]>
Date: Fri, 6 Nov 1992 05:27:14 GMT
Lines: 141

I would appreciate some net.feedback on this matter; bear with
this posting, as it may seem complicated, but the situation is
fundamentally straight forward.

We have been dealing with some cisco router config problems that reflect
some of these issues that people have raised here, and part of
our struggle has been that the manual is too sketchy when it
comes to some basic examples and explanation of how to set some
things up. The basic problem we saw is that when you use
ip unnumbered addressing on serial lines, you have to play some
nasty games to get RIP routing working, and even then you come across
some insurmountable obstacles (these may be bugs, I don't know).
We are running 8.3(3), and we have the following network
configuration (sorry about the size of diagram, hard to make it smaller).


                 Ethernet 192.55.2.x
     ---+-----------------------------------+------------- net1
        |IP 192.55.2.20                     |IP 192.55.2.20
        |                                   |
        |        Ethernet 192.55.1.x        |
        |    --+----------------------------|-------+----- net2
        |      |IP 192.55.1.20              |       |IP 192.55.1.21
        |      |                            |       |
     +------------+                      +-------------+
     |    mgs1    |                      |    mgs2     |
     +------------+                      +-------------+
           |                                    |
           | Serial 9600 link                   | Serial 9600 link
           |                                    |
     +------------+                      +-------------+
     |            |    Serial 9600 link  |             |
     |    cgs1    |----------------------|    cgs2     |
     +------------+                      +-------------+
           |192.55.10.1                         |192.55.11.1
           |                                    |
           | Ethernet 192.55.10.x               | Ethernet 192.55.11.x
     ------+---+---------                -------+---+-------------
               |                                    |
               | IP 192.55.10.2                     | IP 192.55.11.2
       +----------------+                  +----------------+
       |   Annex T/S    |                  |    Annex T/S   |
       +----------------+                  +----------------+
          |  |  |  |  |                       |  |  |  |  |
          | 2400 Baud asynch                  | 2400 Baud asynch
          | Compressed SL/IP                  | Compressed SL/IP
          | IP 192.55.100.1                   | IP 192.55.101.1
       +---------------+                   +---------------+
       |   Remote      |                   |   Remote      |
       |   Telemetry   |                   |   Telemetry   |
       +---------------+                   +---------------+

Essentially we have four routers, with the two MGS's on dual Ethernets
for redundancy; they each have a serial line (all HDLC encap) to
separate CGS's. The CGS's are triangulated so that any one serial line
can fail and you still have a path anywhere. This is only a portion of the
net; eventually there will be 12 CGS's, so to simplify the routing and
addressing, we decided to use ip unnumbered addressing on the serial
lines, where the serial line used the same IP address as the Ethernet
the router was connected to; the idea being that each router/terminal
server cluster was a single net, advertising a static route to the
boxes on the SL/IP side of the terminal server. *BIG MISTAKE*!

The problem with this is that the router will not broadcast a route
to its *own* net on the serial line e.g. When cgs1 broadcasts routes
via RIP to both serial lines, it *will not* include the network 192.55.10.0
in its tables, and so nobody else knows how to get to that network. Nothing
I did convinced the router to include the network in its routing updates.
The only way I saw to overcome this problem was to install a
static route in the routers informing it what the net number of the router
it was connected to e.g. for cgs1:

    ip route 192.55.1.0 serial 0
    ip route 192.55.11.0 serial 1

And cgs2 had:

    ip route 192.55.1.0 serial 0
    ip route 192.55.10.0 serial 1

And all this worked, *except* when you failed one of the serial links.
Again, by example, if the link between mgs1 and cgs1 failed, then
mgs1 would stop advertising the route to cgs1, and hosts would change
their routing tables to go via mgs2 (all well and good). Mgs2 would pass the
packets to cgs2, which would route them to cgs1 - OK, the packet got there
fine, but when a packet is returned, cgs1 still has a static route to
192.55.1.0 via serial 0, EVEN THOUGH THAT INTERFACE IS DOWN. The static
route is *not* overridden even when the router has failed the serial line
(and yes, the router *does* show that interface as down).

There is some talk in the manual about using administrative distance to
override static routes, and so I set up some distances; lo and behold
when you fail the serial link, the routers *do* override the static route
correctly, but when the link is restored the static route is not restored,
so the dynamic route (no longer the best one) is never removed.

After some discussion with the local cisco support (and hearing a few
times `yes, it *should* all work'), we put a different IP address (with
different net number) on all the serial interfaces, and removed the
static routes to the interfaces. *This* works, but it makes the
routing tables much bigger, and everthing looks more complicated.

SPECULATION *ON*

We are seeing two problems here, one a routing issue (possibly
not a bug), and a static route override bug.

Since the IP interfaces are unnumbered, and use the Ethernet IP address,
the router thinks that the serial interface has the same network number
as the Ethernet, and so it *will not* broadcast a route to a network to the
interface that is addressed as that network number, just as it will
not broadcast a network route to the Ethernet that network is on e.g
if a router ethernet interface is 192.55.10.1, then it obviously
will not include a route to network 192.55.10.0 in its RIP advertisement
broadcast on *that* network. The difference is that with a
serial line it is making a wrong assumption, as the router on the
other end of the link does not exist on the same network number,
unlike an Ethernet. The other router, of course, does not know how
to get to that network because the first router is not advertising it, unless
you configure it with a static route to that network pointing to the
serial interface.

Is this a bug? Possibly it is just a bad assumption, but a safe and
conservative one.

The other problem seems more straight forward. When you have a static
route to an interface, and that interface goes down, then the static
route is never overridden, except if you play games with admin. distances,
and then the route is never restored once the link comes up. The frustrating
thing is that the router *knows* the interface is down, but it still
maintains that route in the routing table, even though the interface
is down *and* an alternative path exists. This seems like a bug; if
not a bug, then certainly a difference in opinion about how
static routes to interfaces should operate under interface failure.

Am I expecting too much from the routers?

Andrew McRae            inet:    [e-mail]
Megadata Pty Ltd,        uucp:    ..!uunet!megadata.mega.oz.au!andrew
North Ryde  2113        Phone:    [phone]
NSW    AUSTRALIA        Fax:    [phone]