route dropped when WAN goes down
Joe Nall
server. The SCO server has multiple network interfaces and we are not
on the default interface so a static route has been added to /etc/tcp.
Our WAN connection to this server is down frequently. After many (but
not all) of the network outages the static route to our system is
missing (netstat -rn | grep my-ip-address).
Is this known behavior (dropping a route if the network is
unreachable)?
If so are there any options to the route add command to change this
behavior?
The remote SCO server is not mine, but the admins have been supportive
in trying to resolve the issue. They just don't know how to deal with
the dropped route except to readd the route when we call.
joe
Jeff Liebermann
>I have an application that is communicating with a remote SCO Unix
>server. The SCO server has multiple network interfaces and we are not
>on the default interface so a static route has been added to /etc/tcp.
>Our WAN connection to this server is down frequently. After many (but
>not all) of the network outages the static route to our system is
>missing (netstat -rn | grep my-ip-address).
>
>Is this known behavior (dropping a route if the network is
>unreachable)?
Yep, depending on whether the router was static or dynamic.
If the route was established through an RIP-1 broadcast from the
router, the unspecified version of OSR5 will eventually time out.
However, the static default route should not time out unless
overscribbled by a RIP broadcast announcing a different default route.
This is what is probably happening. There is some contraption on your
knotwork that is belching RIP broadcasts and OSR5 is doing its best to
follow instructions.
If you don't need RIP-1 capabilities on the OSR5 box (i.e you only
have one route to the internet), then simply kill and disable the
routed daemon which is really RIP with a goofy name. Edit the file:
/etc/tcp
and comment out the lines that start routed. If this is a 3.2v5.0.6
or later box, then the proceedure is somewhat different and can be
excavated from somewhere on:
http://support.sco.com
Never mind. Nothing there thanks to SCO removing all the old TA's.
Instead see:
http://aplawrence.com/SCOFAQ/scotec4.html#defaultroute
>If so are there any options to the route add command to change this
>behavior?
Oh probably. However, it would be interesting to first see what
you're using. Something like:
route add default ip_address_of_router
should be sufficient.
>The remote SCO server is not mine, but the admins have been supportive
>in trying to resolve the issue. They just don't know how to deal with
>the dropped route except to readd the route when we call.
--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice http://www.LearnByDestroying.com
# je...@comix.santa-cruz.ca.us
# 831.421.6491 digital_pager je...@cruzio.com AE6KS
Joe Nall
> Yep, depending on whether the router was static or dynamic.
> If the route was established through an RIP-1 broadcast from the
> router, the unspecified version of OSR5 will eventually time out.
> However, the static default route should not time out unless
> overscribbled by a RIP broadcast announcing a different default route.
> This is what is probably happening. There is some contraption on your
> knotwork that is belching RIP broadcasts and OSR5 is doing its best to
> follow instructions.
The route was definitely establised with a manual route add ..
> If you don't need RIP-1 capabilities on the OSR5 box (i.e you only
> have one route to the internet), then simply kill and disable the
> routed daemon which is really RIP with a goofy name. Edit the file:
> /etc/tcp
I'm told that routed is not running and that our route is
the only one that is being lost.
The default route is to the other network.
> and comment out the lines that start routed. If this is a 3.2v5.0.6
> or later box, then the proceedure is somewhat different and can be
> excavated from somewhere on:
uname -a
SCO_SV 3.2 5.06 i386
> Oh probably. However, it would be interesting to first see what
> you're using. Something like:
> route add default ip_address_of_router
> should be sufficient.
They are remote, so I can't verify this, but I was told:
/etc/route add <my-ip> <their-router-ip> >/dev/null 2>&1
was added to /etc/tcp
A route get when things are fine shows
route to: <my-ip>
destination: <my-ip>
gateway: <router-ip>
interface: net0
flags: <UP,GATEWAY,HOST,STATIC,PMTU>
proto: 2, age: 21945
rpipe spipe ssthresh rtt,msec rttvar hopcount mtu
expire tos
0 0 0 1350 502 0 1500
0 0
When they wake up I'll ask them to look at /etc/tcp and verify that
routed is not running.
joe
to...@aplawrence.com
>uname -a
>SCO_SV 3.2 5.06 i386
>> Oh probably. However, it would be interesting to first see what
>> you're using. Something like:
>> route add default ip_address_of_router
>> should be sufficient.
>They are remote, so I can't verify this, but I was told:
>/etc/route add <my-ip> <their-router-ip> >/dev/null 2>&1
>was added to /etc/tcp
Which is about the worst possible place to do it, especially
for 5.0.6.
See http://aplawrence.com/SCOFAQ/FAQ_defaultroute.html
--
to...@aplawrence.com Unix/Linux/Mac OS X resources: http://aplawrence.com
Get paid for writing about tech: http://aplawrence.com/publish.html
Jeff Liebermann
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<0h88kv03uf3oa1coo...@4ax.com>...
>
>> Yep, depending on whether the router was static or dynamic.
I need a proof reader. That should be "route", not "router". Argh.
>I'm told that routed is not running
Run:
ps -ef | grep routed
If routed is running, disarm the monster.
>and that our route is
>the only one that is being lost.
>The default route is to the other network.
OK. You have a static route established somewhere. I'll assume that
the default route is still intact after the static route is being
trashed. I'm still partial to adding it to the file:
/etc/rc2.d/S99route
Since I have no clue if your added route is for a -host or a -net, I
can't supply a suitable example. There is a flag to make the route
permanent.
http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?route+ADMN
Methinks the
-expire 0
option might work. I've never tried it.
>uname -a
>SCO_SV 3.2 5.06 i386
See:
http://aplawrence.com/SCOFAQ/FAQ_defaultroute.html
>They are remote, so I can't verify this, but I was told:
>/etc/route add <my-ip> <their-router-ip> >/dev/null 2>&1
>was added to /etc/tcp
No. Don't add a static route to /etc/tcp. Use or add a file
something like:
/etc/rc2.d/S99route
Incidentally, if you're hacking away remotely, do *NOT* run:
route flush
That will vaporize all routes, including the route you're using to get
to the server. You'll find youself disconnected until a reboot can be
scheduled.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
je...@comix.santa-cruz.ca.us je...@cruzio.com
Joe Nall
> Run:
> ps -ef | grep routed
> If routed is running, disarm the monster.
Had them do that this moning - no routed
/etc/tcp does not launch routed
> OK. You have a static route established somewhere. I'll assume that
> the default route is still intact after the static route is being
> trashed.
Correct, a number of other static routes are still intact also.
> Since I have no clue if your added route is for a -host or a -net, I
> can't supply a suitable example. There is a flag to make the route
> permanent.
> http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?route+ADMN
> Methinks the
> -expire 0
> option might work.
I'm going to ask them to try:
/etc/route add -lock -expire 0 -host <my-ip> <gateway-ip>
They are running "route monitor" right now in the hope that it will
point to why the routing table is being modified.
> Incidentally, if you're hacking away remotely, do *NOT* run:
> route flush
> That will vaporize all routes,
good advice :)
joe
Jeff Liebermann
>Had them do that this moning - no routed
>/etc/tcp does not launch routed
It's in there somewhere. Try:
/etc/default/tcp
for hints. If routed is NOT running, my guess(tm) as to what's
happening is probably wrong. However, the route could be simply
timing out when the link drops. As you indicate, try the various
route command options.
>I'm going to ask them to try:
>/etc/route add -lock -expire 0 -host <my-ip> <gateway-ip>
Sounds reasonable.
>They are running "route monitor" right now in the hope that it will
>point to why the routing table is being modified.
Good idea. However, monitoring is best done with a script. Something
like:
while :
do
date >> /tmp/route.log
route monitor >> /tmp/route.log
netstat -rn >> /tmp/route.log
sleep 60
done
The timing is the key, where whatever else was happening on the
network at the same time is the probable culprit. I had a similar
headache that was traced to some experimental software going insane on
startup on a different machine.
Joe Nall
> They are running "route monitor" right now in the hope that it will
> point to why the routing table is being modified.
Here is their report on /etc/route -n monitor while the route was
being dropped
(hand typed):
RTM_CHANGE: change metrics or flags
len: 136 pid: 0 seq: 0 errno: 0
flags: <GATEWAY, HOSTS, DONE>
proto: age: (number varies)
sockaddres;<DST, GATEWAY> (MY-IP) (IP2) (IP3)
RTM_MISS: Look up failed on the address
len: 104 pid: 0 seq: 0 errno: 117
flags: <DONE>
proto: age: (number varies)
locks: , inits:
sockaddres;<DST> (MY-IP)
Where (MY-IP) is the IP address of my server (the one whose route is
being dropped). Any interpretation would be appreciated.
They swear routed is not running.
joe
Jeff Liebermann
>j...@nall.com (Joe Nall) wrote in message news:<9d1ed006.03082...@posting.google.com>...
>> They are running "route monitor" right now in the hope that it will
>> point to why the routing table is being modified.
>
>Here is their report on /etc/route -n monitor while the route was
>being dropped
>(hand typed):
>
>RTM_CHANGE: change metrics or flags
>len: 136 pid: 0 seq: 0 errno: 0
>
>flags: <GATEWAY, HOSTS, DONE>
>proto: age: (number varies)
>sockaddres;<DST, GATEWAY> (MY-IP) (IP2) (IP3)
>Where (MY-IP) is the IP address of my server (the one whose route is
>being dropped). Any interpretation would be appreciated.
Not much useful there. What is IP2 and IP3? Are there two ethernet
cards in this box with ipredirects (IP forwarding) enabled between the
two cards? My guess(tm) is that the change involved the route between
the two cards (IP2 and IP3). Otherwise, could you dummy up some IP
addresses instead of variables? My brain works better without the
symbolics.
>They swear routed is not running.
OK, let's assume that they're right. (Assumption, the mother off all
screwups). Any chance that they're running gated instead of routed?
It would also show up in the process table as:
ps -ef | grep "gated" (actually in.gated)
See:
http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?gated+ADMN
Someone has to be running RIP. So, let's go shopping for the culprit.
Run:
ripquery -n gateway_IP_address
ripquery -n local_IP_address
If you get "connection refused" or something similar, it's not running
RIP 2. Also try the -1 flag in case it's running RIP 1. Try every IP
address on your LAN. Devices running either routed or gated will
respond.
http://osr5doc.ca.caldera.com:457/cgi-bin/man/man?ripquery+ADMN
Joe Nall
> screwups). Any chance that they're running gated instead of routed?
> It would also show up in the process table as:
> ps -ef | grep "gated" (actually in.gated)
I had them check, they found the 'grep gated' process - but no
in.gated.
> Someone has to be running RIP. So, let's go shopping for the culprit.
> Run:
> ripquery -n gateway_IP_address
> ripquery -n local_IP_address
> If you get "connection refused" or something similar, it's not running
> RIP 2. Also try the -1 flag in case it's running RIP 1. Try every IP
> address on your LAN.
They say that there is no response at all. Just a return to the
command prompt.
Since this is really affecting business, I'm going to recommend
installing a cron job that will test for the correct route and reload
it as required while we hunt for the culprit. Ugly, but it should be
effective.
joe
Jeff Liebermann
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote in message news:<4d7bkvkorf3b6anl0...@4ax.com>...
>Since this is really affecting business, I'm going to recommend
>installing a cron job that will test for the correct route and reload
>it as required while we hunt for the culprit. Ugly, but it should be
>effective.
>joe
Sigh. Sorry, I'm out of ideas that can be tested remotely. My next
step would be a packet sniffer synchronized with
route -n monitor
to catch when the route changed. The idea is to identify the source
of the packets. However, without RIP running, I can't see how the
route is being changed externally. Dunno.