A.P. Lawrence

overlapping routes different subnets

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@sco.com>
Subject: Re: Strange Problem on OSR 5.0.6 routing/ping after Caldera 2.4 ppp connection
Date: Thu, 28 Jun 2001 23:40:35 GMT References: <Pine.SC5.4.30.0106281115001.17003-100000@xenau>

Boyd Lynn Gerber wrote:

> I have a client that connects to my OSR 5.0.6 box with all the patches
> installed from the SCO site.
> 
> Before ppp connection.
> 
> ping 166.70.62.2 works while on 166.70.62.2 or any other alias.
> 
> After ppp connects using caldera 2.4 and kppp the machine dumps mail via
> pop3 and smtp then the problem begins.  All the updates from
> ftp.caldera.com /pub/updates/eDestop/2.4/current as of 6/27 are
> installed.  His machine has diconnected from my machine.
> 
> I try to ping 166.70.62.2 from 166.70.62.2 I get host is down or any other
> alias.  But netstat -nr is exactly the same.  I can telnet, ping,
> traceroute,... from any other host on the network to 166.70.62.2 or an
> alias.  But the only telnet or ping while on 166.70.62.2 that works is
> localhost or 127.0.0.1.
> 
> $ netstat -nr
> 
> Destination      Gateway            Flags    Refs      Use  Interface
> default          166.70.62.1        UGS         4    44998  net0
> 127.0.0.1        127.0.0.1          UH         15    22094  lo0
> 166.70.62        166.70.62.2        UC          1        0  net0
> 166.70.62        166.70.62.5        UC          1        0  net0

Notice that you have two different routes to 166.70.62.  I don't think
this should be.  The reason is apparent below...

> 166.70.62.2      127.0.0.1          UGHS        4     4504  lo0
> 166.70.62.5      127.0.0.1          UGHS        0        0  lo0
> 166.70.62.12     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.13     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.15     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.16     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.43     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.45     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.47     127.0.0.1          UGHS        0        0  lo0
> 166.70.62.49     127.0.0.1          UGHS        0        0  lo0
> 166.70.63        166.70.63.1        UC          1        0  net0

This route also figures into the discussion below.

Lone-Tar Backup and Disaster Recovery
for Linux and Unix

> 166.70.63.1      127.0.0.1          UGHS        0        0  lo0
> 166.70.63.2      127.0.0.1          UGHS        0        0  lo0
> 166.70.63.3      127.0.0.1          UGHS        0        0  lo0
> 198.60.105       198.60.105.2       UC          1        0  net0
> 198.60.105.2     127.0.0.1          UGHS        0        0  lo0
> 224              166.70.62.2        UCS         0        0  net0
> 
> and
> 
> $ ifconfig -a
> net0: flags=4043<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
>         inet 166.70.62.2 netmask fffffe00 broadcast 166.70.63.255

Notice that the netmask here is 255.255.254.0, whereas...

>         perf. params: recv size: 24576; send size: 24576; full-size frames: 1
>         ether 00:60:97:d6:0d:30
>         (alias) inet 198.60.105.2 netmask ffffff00 broadcast 198.60.105.255
>         (alias) inet 166.70.62.5 netmask ffffff00 broadcast 166.70.62.255

... this is 255.255.255.0.  So the two routes above represent (1) a way
to get to a 9-bit subnet, addresses 166.70.62.0 through 166.70.63.255,
and (2) a way to get to an 8-bit subnet, addresses 166.70.62.0 through
166.70.62.255.  Plus, of course, another route to get to 8 bits worth of
166.70.63.0 through 255, via 166.70.63.1.

I don't think the kernel's expecting to find routes like that.  Don't
know how they got there -- whether you deliberately set up the route
which spans the 9-bit combined subnet, or what.

>         (alias) inet 166.70.62.12 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.13 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.15 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.16 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.43 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.45 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.47 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.62.49 netmask ffffff00 broadcast 166.70.62.255
>         (alias) inet 166.70.63.1 netmask ffffff00 broadcast 166.70.63.255
>         (alias) inet 166.70.63.2 netmask ffffff00 broadcast 166.70.63.255
>         (alias) inet 166.70.63.3 netmask ffffff00 broadcast 166.70.63.255
> lo0: flags=4049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 8232
>         inet 127.0.0.1 netmask ff000000
>         perf. params: recv size: 57344; send size: 57344; full-size frames: 1
> atl0: flags=404a<BROADCAST,LOOPBACK,RUNNING,MULTICAST> mtu 8232
>         inet 0.0.0.0 netmask ff000000
>         perf. params: recv size: 4096; send size: 8192; full-size frames: 1
> 
> Does any one have any ideas on what went wrong?  Some times it will
> recover and work and other time I have to take tcp down and back up or
> reboot the machine.

Figure out how you're creating the overlapping routes and I'm sure the
problem will disappear...

>Bela<

Enter your email address for automatic notification of new posts here
(be sure to whitelist 'feedburner.com' if you use spam filtering)

/Bofcusm/1323.html copyright 1997-2004 Bela Lubkin All Rights Reserved

Have you tried Searching this site?

Unix/Linux/Mac OS X support by phone, email or on-site: Support Rates

This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.

Publishing your articles here