SEO

Hey,

We are migrating our network from a 192.100.100.0 subnet to a
192.168.1.0 subnet and I am having problems with our SCO 5.0.4 boxes.

One box is configured to run an end-of-day procedure and print reports
at 04:30. The printer doesn't start printing until 07:00 or later
sometimes. Under normal circumstances it would start printing at
04:34. This box has an IP address of 192.168.1.9 and the printer is
at 192.100.100.179. Here is it's routing table:

# netstat -rn
Routing tables
Destination Gateway Flags Refs Use Interface
default 192.168.1.251 UGS 5 227476 net1
127.0.0.1 127.0.0.1 UH 3 620393 lo0
192.168.1 192.168.1.9 UC 1 0 net1
192.168.1.9 127.0.0.1 UGHS 0 1630 lo0
224 192.168.1.9 UCS 0 0 net1

The router at the default gateway (192.168.1.251) is a Cisco 1721 set
up to pass all traffic between the two subnets.

The problem only seems to happen if the server hasn't been accessed by
a host on the other subnet (or tried to access a host on the other
subnet).

So far I have only noticed this happening with SCO boxes. My Windows
XP PC is on the new subnet and I don't have any problems connecting to
any hosts on either network (except SCO boxes).

Does anyone know what might be causing this or have any ideas on how
to fix it?


Later

David Kirk

On Mon, 05 Apr 2004 11:02:11 +1200, David Kirk
<davidrkirk.NOSPAM@hotmail.com> wrote:

>We are migrating our network from a 192.100.100.0 subnet to a
>192.168.1.0 subnet and I am having problems with our SCO 5.0.4 boxes.

Be advised that RFC1918 designates 192.168.xxx.xxx and others for use
in private LAN's. Although you can probably make 192.100.100.xxx
work, I would not recommend it. Changeing the 2nd octet from 100 to
168 would not be a major project.

Was this working properly *BEFORE* you twiddled with the IP addresses?

>One box is configured to run an end-of-day procedure and print reports
>at 04:30. The printer doesn't start printing until 07:00 or later
>sometimes. Under normal circumstances it would start printing at
>04:34.

Ummm, what does the aformentioned have to do with a routing problem?

>This box has an IP address of 192.168.1.9 and the printer is
>at 192.100.100.179.

># netstat -rn
>Routing tables
>Destination Gateway Flags Refs Use Interface
>default 192.168.1.251 UGS 5 227476 net1
>127.0.0.1 127.0.0.1 UH 3 620393 lo0
>192.168.1 192.168.1.9 UC 1 0 net1
>192.168.1.9 127.0.0.1 UGHS 0 1630 lo0
>224 192.168.1.9 UCS 0 0 net1

Ok, packets to 192.168.100.179 are going out the default route to the
internet. That's ok.

>The router at the default gateway (192.168.1.251) is a Cisco 1721 set
>up to pass all traffic between the two subnets.

I'll take your word for it. Try using traceroute on the SCO box to
see where the packets go between the SCO box and the remote printer.

>The problem only seems to happen if the server hasn't been accessed by
>a host on the other subnet (or tried to access a host on the other
>subnet).

What problem? You haven't described what does NOT work or what you're
trying to achieve. My guess(tm) is that you can't print to the remote
printer.
Can you ping the remote printer?

If "accessing" (I hate that word, it's so meaningless) the SCO server
by a local machine on the remote LAN, it could easily be problem with
whatever you're using for an ethernet switch. A switch needs to see
traffic in order to obtain the MAC address of the SCO box. One would
think that the SCO box belches enough broadcasts to not require
priming, but it's possible. Does pinging the remote SCO box give the
same results as "accessing" the SCO box?

>So far I have only noticed this happening with SCO boxes.

You have more than one OSR5 box? Have all the boxes had their IP
address's and/or names changed or just one?

>My Windows
>XP PC is on the new subnet and I don't have any problems connecting to
>any hosts on either network (except SCO boxes).

OK, so the undefined problem is unique to the SCO box. The first step
to solving a problem is blame someone (or something). The SCO box
will do.

>Does anyone know what might be causing this or have any ideas on how
>to fix it?

Sure.

1. See:
http://www.LearnByDestroying.com/sco/new_name.txt
for a shopping list of files that have the IP address imbedded. You
probably missed one somewhere. Methinks this is the most likely
culprit.

2. SCO has the nasty habit of running the "routed" daemon which is
RIP1. If you have any routers or broken Microsoft impersonations of a
server that advertises RIP1 routes, SCO 3.2v5.0.4 will happily send
the default route off to who knows where. I advise that you kill the
"routed" daemon, and edit the file /etc/tcp to comment out the lines
that start routed. This was sorta fixed in 3.2v5.0.6. I suggest you
do this even if you find the solution elsewhere.

3. Flakey NWAY negotiation on ethernet switch together with buggy
3Scum ethernet cards that result in the card set to full-duplex, while
the switch lands in half-duplex. The result is moderate packet loss.
It will still work but act erratic with occassional hangs. Try file
copies in both directions between one of the local machines and the
SCO box. If the bits/sec numbers in both directions look reasonable,
you don't have this problem. If it hangs, acts erratic, or is
asymetrical, you have a problem.


--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com

On Sun, 04 Apr 2004 17:59:28 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote:

Jeff,

Sorry I haven't been very clear. See my comments inline.

>On Mon, 05 Apr 2004 11:02:11 +1200, David Kirk
><davidrkirk.NOSPAM@hotmail.com> wrote:
>
>>We are migrating our network from a 192.100.100.0 subnet to a
>>192.168.1.0 subnet and I am having problems with our SCO 5.0.4 boxes.
>
>Be advised that RFC1918 designates 192.168.xxx.xxx and others for use
>in private LAN's. Although you can probably make 192.100.100.xxx
>work, I would not recommend it. Changeing the 2nd octet from 100 to
>168 would not be a major project.

That is the whole point of this change. Our local LAN uses
192.100.100.0/24 which is owned by other people out there on the
Internet. We are moving to the 192.168.1.0/24 subnet.

Although we have a firewall which does NAT from our 192.100.100.x
addresses to our external address, the new subnet will comply with
RFC1918.

>Was this working properly *BEFORE* you twiddled with the IP addresses?

Yes, but we only had a single subnet, so we didn't even have a gateway
setup.

>>One box is configured to run an end-of-day procedure and print reports
>>at 04:30. The printer doesn't start printing until 07:00 or later
>>sometimes. Under normal circumstances it would start printing at
>>04:34.
>
>Ummm, what does the aformentioned have to do with a routing problem?

The printer is a network printer. It is not attached to the SCO box
directly. It has a JetDirect card in it. The end of day reports get
stuck in the print queue until something (I don't know what) allows
the server to connect to the remote printer.

>>This box has an IP address of 192.168.1.9 and the printer is
>>at 192.100.100.179.
>
>># netstat -rn
>>Routing tables
>>Destination Gateway Flags Refs Use Interface
>>default 192.168.1.251 UGS 5 227476 net1
>>127.0.0.1 127.0.0.1 UH 3 620393 lo0
>>192.168.1 192.168.1.9 UC 1 0 net1
>>192.168.1.9 127.0.0.1 UGHS 0 1630 lo0
>>224 192.168.1.9 UCS 0 0 net1
>
>Ok, packets to 192.168.100.179 are going out the default route to the
>internet. That's ok.
>
>>The router at the default gateway (192.168.1.251) is a Cisco 1721 set
>>up to pass all traffic between the two subnets.
>
>I'll take your word for it. Try using traceroute on the SCO box to
>see where the packets go between the SCO box and the remote printer.
>
>>The problem only seems to happen if the server hasn't been accessed by
>>a host on the other subnet (or tried to access a host on the other
>>subnet).
>
>What problem? You haven't described what does NOT work or what you're
>trying to achieve. My guess(tm) is that you can't print to the remote
>printer.

The problem is that hosts on the old subnet (including the printer)
cannot connect to the server and vice versa. Telnet, ping, printing,
etc don't work between subnets.

> Can you ping the remote printer?

No.

>If "accessing" (I hate that word, it's so meaningless) the SCO server
>by a local machine on the remote LAN, it could easily be problem with
>whatever you're using for an ethernet switch. A switch needs to see
>traffic in order to obtain the MAC address of the SCO box. One would
>think that the SCO box belches enough broadcasts to not require
>priming, but it's possible. Does pinging the remote SCO box give the
>same results as "accessing" the SCO box?

Yep. "Accessing" = telnet or ping

>>So far I have only noticed this happening with SCO boxes.
>
>You have more than one OSR5 box? Have all the boxes had their IP
>address's and/or names changed or just one?

I have another one that I am changing tomorrow morning. Hosts on the
new subnet can't ping or telnet to it.

Did I mention that the problem is intermittent. This morning when I
came in to the office, I couldn't ping the server on the other subnet.
Sometime during my troubleshooting, it started working and has done
all day. The problem seems to only occur when no hosts on the other
network have communicated for some undetermined amount of time.

>>My Windows
>>XP PC is on the new subnet and I don't have any problems connecting to
>>any hosts on either network (except SCO boxes).
>
>OK, so the undefined problem is unique to the SCO box. The first step
>to solving a problem is blame someone (or something). The SCO box
>will do.

I am blaming the SCO boxes, but I haven't completely ruled out the
router yet either.

>>Does anyone know what might be causing this or have any ideas on how
>>to fix it?
>
>Sure.
>
>1. See:
> http://www.LearnByDestroying.com/sco/new_name.txt
>for a shopping list of files that have the IP address imbedded. You
>probably missed one somewhere. Methinks this is the most likely
>culprit.

Nice. Thanks for that. I will check those files out.

I've already found that the old broadcast address was still in
/etc/default/tcp.

>2. SCO has the nasty habit of running the "routed" daemon which is
>RIP1. If you have any routers or broken Microsoft impersonations of a
>server that advertises RIP1 routes, SCO 3.2v5.0.4 will happily send
>the default route off to who knows where. I advise that you kill the
>"routed" daemon, and edit the file /etc/tcp to comment out the lines
>that start routed. This was sorta fixed in 3.2v5.0.6. I suggest you
>do this even if you find the solution elsewhere.

Done. Hopefully it will help.

>3. Flakey NWAY negotiation on ethernet switch together with buggy
>3Scum ethernet cards that result in the card set to full-duplex, while
>the switch lands in half-duplex. The result is moderate packet loss.
>It will still work but act erratic with occassional hangs. Try file
>copies in both directions between one of the local machines and the
>SCO box. If the bits/sec numbers in both directions look reasonable,
>you don't have this problem. If it hangs, acts erratic, or is
>asymetrical, you have a problem.

Both NIC and switch are forced to 100-FD.

Thanks for your help.


Later

David Kirk

On Mon, 05 Apr 2004 15:54:59 +1200, David Kirk
<davidrkirk.NOSPAM@hotmail.com> wrote:

>That is the whole point of this change. Our local LAN uses
>192.100.100.0/24 which is owned by other people out there on the
>Internet. We are moving to the 192.168.1.0/24 subnet.

No problem. However, you're doing it all wrong. You really should
look into a VPN. I struggled with shovelling multiple socket based
services through a single IP address with routeing in the past and
have literally given up. It can be done, but it's not worth the
effort. A VPN is the only way to fly. You get all the benifits of an
encrypted data stream (something you don't get with just routeing) as
well as a totally transparent LAN, where all the IP socket numbers at
both ends are visible.
(End of sales pitch).

>>Was this working properly *BEFORE* you twiddled with the IP addresses?
>
>Yes, but we only had a single subnet, so we didn't even have a gateway
>setup.

Ok, so this is essentially a new topology.

>The printer is a network printer. It is not attached to the SCO box
>directly. It has a JetDirect card in it. The end of day reports get
>stuck in the print queue until something (I don't know what) allows
>the server to connect to the remote printer.

The default setup for JetDirect boxes is to have the IP address
assigned by DHCP. Are you sure that the printer has the desired IP
address? Are you sure that it will stay that way? I suggest you
either use a "static DHCP" assignment, or a static IP address in the
print server.

>The problem is that hosts on the old subnet (including the printer)
>cannot connect to the server and vice versa. Telnet, ping, printing,
>etc don't work between subnets.

Yep. That's the way it's suppose to work between sub-nets. The whole
idea behind subnets is to seperate the traffic. If you plugged both
subnets into the same network without the router, you still would not
be able to communicate. The router(s) need to provide the connection
between the two networks. Think VPN.

>> Can you ping the remote printer?
>No.

Ok. Let's start at the printer and work backwards to see where things
stop. I already know the answer but the method will be necessary for
testing when you get it together.
1. Can you ping the print server from a local PC on the local
network?
2. If yes, can you ping it from the SCO box?
3. If yes, can you ping it from the remote router using Cisco's
diagnostics?
4. If yes, can you ping it from the internet? (not for VPN).
5. If yes, can you ping it from the other router using Cisco's
diagnostics?
6. if yes, can you ping it from a workstation or server on the other
network?

Can you see how this works? Start at one end and work backwards
toward yourself. Where the pings fail, is the problem.

>I have another one that I am changing tomorrow morning. Hosts on the
>new subnet can't ping or telnet to it.

Same issue, same problem. That means that there's probably nothing
defective in the hardware.

>Did I mention that the problem is intermittent. This morning when I
>came in to the office, I couldn't ping the server on the other subnet.
>Sometime during my troubleshooting, it started working and has done
>all day. The problem seems to only occur when no hosts on the other
>network have communicated for some undetermined amount of time.

Is this a dialup connection? The intermittants might be due to the
line going down. You might wanna deploy some kind of network uptime
or graphing program to check if the line is going up or down. I use
MRTG and "Whats up". Dropping the connection when the traffic is low
sounds like a router/dialup issue.

You might also be suffering from excessive traffic. If one of your
workstations has been compromised by a worm or other traffic
generating junkware, it could simulate a dropped connection because it
occupies all the bandwidth.

>I've already found that the old broadcast address was still in
>/etc/default/tcp.

Keep going. There's more. Running
netconfig
and
uname -S new_name
changes most of the settings, but not all of them.

>Both NIC and switch are forced to 100-FD.

There's no guarantee that the SCO box will comply. What type of NIC
is in the SCO boxes? I suggest you force the switch ports to 10barf-T
half-duplex, or the lowest possible NWAY technology until you have
everything working. You may need to power off the SCO box to get the
NIC to reset.

Good luck.


--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com

In article <gho1705k2gaccmc2pknc6r4op38m9s9281@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>On Mon, 05 Apr 2004 15:54:59 +1200, David Kirk
><davidrkirk.NOSPAM@hotmail.com> wrote:

>>That is the whole point of this change. Our local LAN uses
>>192.100.100.0/24 which is owned by other people out there on the
>>Internet. We are moving to the 192.168.1.0/24 subnet.

>No problem. However, you're doing it all wrong. You really should
>look into a VPN. I struggled with shovelling multiple socket based
>services through a single IP address with routeing in the past and
>have literally given up. It can be done, but it's not worth the
>effort. A VPN is the only way to fly. You get all the benifits of an
>encrypted data stream (something you don't get with just routeing) as
>well as a totally transparent LAN, where all the IP socket numbers at
>both ends are visible.
>(End of sales pitch).

>>>Was this working properly *BEFORE* you twiddled with the IP
>>>addresses?

>>Yes, but we only had a single subnet, so we didn't even have a gateway
>>setup.

>Ok, so this is essentially a new topology.

>>The printer is a network printer. It is not attached to the SCO box
>>directly. It has a JetDirect card in it. The end of day reports get
>>stuck in the print queue until something (I don't know what) allows
>>the server to connect to the remote printer.
>
>The default setup for JetDirect boxes is to have the IP address
>assigned by DHCP. Are you sure that the printer has the desired IP
>address? Are you sure that it will stay that way? I suggest you
>either use a "static DHCP" assignment, or a static IP address in the
>print server.

>>The problem is that hosts on the old subnet (including the printer)
>>cannot connect to the server and vice versa. Telnet, ping, printing,
>>etc don't work between subnets.

>Yep. That's the way it's suppose to work between sub-nets. The whole
>idea behind subnets is to seperate the traffic. If you plugged both
>subnets into the same network without the router, you still would not
>be able to communicate. The router(s) need to provide the connection
>between the two networks. Think VPN.

If the router is even semi-smart then he could perhaps assign
both base networks the 192.168.100.0/24 and the 192.168.1.0/24
to the same interface [in Cicso it would be called secondary]
and have the router divert packtes for the 192.168.100.0/24
to the 192.168.1.0/24. It would only make the the 192.168.100.0/24
network unreachable, but make his local net work until the
migration is finished.

I suspect his router is set to forward all non 192.168.1 address
out to the real world.

A smarter switch could also do the same.

Bill

--
Bill Vermillion - bv @ wjv . com

On Sun, 04 Apr 2004 21:57:06 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote:

>On Mon, 05 Apr 2004 15:54:59 +1200, David Kirk
><davidrkirk.NOSPAM@hotmail.com> wrote:
>
>>That is the whole point of this change. Our local LAN uses
>>192.100.100.0/24 which is owned by other people out there on the
>>Internet. We are moving to the 192.168.1.0/24 subnet.
>
>No problem. However, you're doing it all wrong. You really should
>look into a VPN. I struggled with shovelling multiple socket based
>services through a single IP address with routeing in the past and
>have literally given up. It can be done, but it's not worth the
>effort. A VPN is the only way to fly. You get all the benifits of an
>encrypted data stream (something you don't get with just routeing) as
>well as a totally transparent LAN, where all the IP socket numbers at
>both ends are visible.
>(End of sales pitch).

All of this is happening on our local LAN. Both subnets are on the
same piece of wire, but of course they won't talk to each other
without the router. There are no WAN links or Internet involved.

All of our network was on 192.100.100.0/24 and I am changing all of
the network to a 192.168.1.0/24 network. The router is only here for
the duration of the migration.

Here is how I am handling the migration. Each box retains their old
192.100.100.x address and also gets an alias address of 192.168.1.x.
I update DNS with the new address and once everyone's DNS caches have
expired, I remove the old address.

>>>Was this working properly *BEFORE* you twiddled with the IP addresses?
>>
>>Yes, but we only had a single subnet, so we didn't even have a gateway
>>setup.
>
>Ok, so this is essentially a new topology.
>
>>The printer is a network printer. It is not attached to the SCO box
>>directly. It has a JetDirect card in it. The end of day reports get
>>stuck in the print queue until something (I don't know what) allows
>>the server to connect to the remote printer.
>
>The default setup for JetDirect boxes is to have the IP address
>assigned by DHCP. Are you sure that the printer has the desired IP
>address? Are you sure that it will stay that way? I suggest you
>either use a "static DHCP" assignment, or a static IP address in the
>print server.

The JetDirect is still set to use DHCP. The address hasn't changed
since the printer was installed. When I move it to the other subnet
it will have a static address.

>>The problem is that hosts on the old subnet (including the printer)
>>cannot connect to the server and vice versa. Telnet, ping, printing,
>>etc don't work between subnets.
>
>Yep. That's the way it's suppose to work between sub-nets. The whole
>idea behind subnets is to seperate the traffic. If you plugged both
>subnets into the same network without the router, you still would not
>be able to communicate. The router(s) need to provide the connection
>between the two networks. Think VPN.

Yep, that's how it works with everything else.

>>> Can you ping the remote printer?
>>No.
>
>Ok. Let's start at the printer and work backwards to see where things
>stop. I already know the answer but the method will be necessary for
>testing when you get it together.

Unfortunately (?) I can't test it at the moment because it all works
and I don't know how to replicate the fault other than wait until
tomorrow morning :-( I can answer some of them from my previous
testing though.

>1. Can you ping the print server from a local PC on the local
>network?

Yes.

>2. If yes, can you ping it from the SCO box?

No.

>3. If yes, can you ping it from the remote router using Cisco's
>diagnostics?
>4. If yes, can you ping it from the internet? (not for VPN).

Hell no. Neither the printer nor the server have access to the
Internet.

>5. If yes, can you ping it from the other router using Cisco's
>diagnostics?

There is only 1 router with 2 interfaces (1 for each subnet).

>6. if yes, can you ping it from a workstation or server on the other
>network?
>
>Can you see how this works? Start at one end and work backwards
>toward yourself. Where the pings fail, is the problem.

Yes, very logical. I will have another go at this next time it fails.
Because it is the SCO box that is the problem though, I think I should
probable see what I can ping from the SCO box. Eg. localhost, another
host on same subnet, router local interface, router remote interface,
host on other subnet. That should more accurately find the fault.

>>I have another one that I am changing tomorrow morning. Hosts on the
>>new subnet can't ping or telnet to it.
>
>Same issue, same problem. That means that there's probably nothing
>defective in the hardware.
>
>>Did I mention that the problem is intermittent. This morning when I
>>came in to the office, I couldn't ping the server on the other subnet.
>>Sometime during my troubleshooting, it started working and has done
>>all day. The problem seems to only occur when no hosts on the other
>>network have communicated for some undetermined amount of time.
>
>Is this a dialup connection? The intermittants might be due to the
>line going down. You might wanna deploy some kind of network uptime
>or graphing program to check if the line is going up or down. I use
>MRTG and "Whats up". Dropping the connection when the traffic is low
>sounds like a router/dialup issue.
>
>You might also be suffering from excessive traffic. If one of your
>workstations has been compromised by a worm or other traffic
>generating junkware, it could simulate a dropped connection because it
>occupies all the bandwidth.
>
>>I've already found that the old broadcast address was still in
>>/etc/default/tcp.
>
>Keep going. There's more. Running
> netconfig
>and
> uname -S new_name
>changes most of the settings, but not all of them.

I didn't find any other significant problems with any of those files.

>>Both NIC and switch are forced to 100-FD.
>
>There's no guarantee that the SCO box will comply. What type of NIC
>is in the SCO boxes? I suggest you force the switch ports to 10barf-T
>half-duplex, or the lowest possible NWAY technology until you have
>everything working. You may need to power off the SCO box to get the
>NIC to reset.

It is a HP Netserver 10/100 TX LAN Adapter. It's never caused
problems before. The only thing that has changed is the IP address.
I don't think that is the problem.

>Good luck.

Thanks.

On Tue, 06 Apr 2004 09:17:31 +1200, David Kirk
<davidrkirk.NOSPAM@hotmail.com> wrote:

>All of this is happening on our local LAN. Both subnets are on the
>same piece of wire, but of course they won't talk to each other
>without the router. There are no WAN links or Internet involved.

Now you tell me. This is what threw me:
"The router at the default gateway (192.168.1.251) is a Cisco 1721 set
up to pass all traffic between the two subnets."
Lacking any info on the topology, I just assumed that you were
routeing between two subnets over the internet. Grumble...

>All of our network was on 192.100.100.0/24 and I am changing all of
>the network to a 192.168.1.0/24 network. The router is only here for
>the duration of the migration.

I've done a few IP migrations in the past. I vaguely recall the 2nd
one was done in stages, with a temporary router similar to your
method. There's some networking book that recommends doing it that
way. What happened was the Cisco expert spent the entire weekend
bludgeoning the router and networks into some semblence of
functionality. Fortunately, it was over a weekend. By the 11th hour
(actually 23rd hour), the router expert was still having a bad day. I
finally decided that it wasn't going to work and manually reconfigured
about 100 desktops in 3 locations. It took the rest of the night, but
on Monday morning, everything worked. I turned off the router.

>Here is how I am handling the migration. Each box retains their old
>192.100.100.x address and also gets an alias address of 192.168.1.x.
>I update DNS with the new address and once everyone's DNS caches have
>expired, I remove the old address.

Don't forget the WINS cache, NETBIOS name cache, various HOSTS and
LMHOSTS files, etc. Yeah, great idea. I've done it that way and
managed to "forget" necessary changes. The problem is that everything
had to get fixed twice. Once to get the multi-address configuration
to play, and once again when I had to get rid of it. Is there a
reason you can't just change everything at once? Why prolong the
ordeal?

I vaguely recall that there was some kind of bug in the alias
mechanism in 3.2v5.0.4 that was later fixed. I'll dig when I get to
the office (timer permitting).

>The JetDirect is still set to use DHCP. The address hasn't changed
>since the printer was installed. When I move it to the other subnet
>it will have a static address.

Well, if it's currently set for DHCP, are you sure that it has the
right address? My nightmare was having multiple DHCP servers running
on a LAN. It happens almost every time someone tinkers with a
wireless router. I have arpwatch running to detect such problems on
mission critical networks. Lately, I've been using "static DHCP" to
assign IP addresses to print servers. The idea is to build a table of
MAC address and IP address pairs in the router that's running DHCP,
and reserve the IP's for those devices. I haven't figured out an
effective backup scheme in case the DHCP server dies, but that hasn't
been much of a problem with long lease times.

>Unfortunately (?) I can't test it at the moment because it all works
>and I don't know how to replicate the fault other than wait until
>tomorrow morning :-( I can answer some of them from my previous
>testing though.

Well, if it's intermittant, then it's probably the RIP1 (routed)
problem. That means you have a router or server on your LAN that's
spewing RIP announcements. Find and disable. It will break other
devices.

>There is only 1 router with 2 interfaces (1 for each subnet).

With every IP port transparently routed between both networks?

>Yes, very logical. I will have another go at this next time it fails.
>Because it is the SCO box that is the problem though, I think I should
>probable see what I can ping from the SCO box. Eg. localhost, another
>host on same subnet, router local interface, router remote interface,
>host on other subnet. That should more accurately find the fault.

Yep. The pattern should be obvious. I still think there's some
obscure file on the OSR5 boxes that haven't had their IP address
tweaked. I know you said you checked everything, but I'm still
suspicious.


--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)336-2558 home
http://www.LearnByDestroying.com AE6KS
jeffl@comix.santa-cruz.ca.us jeffl@cruzio.com

In article <2op570hbtj53svg2u11jjd7b85e86vbk1l@4ax.com>,
Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:

>Well, if it's currently set for DHCP, are you sure that it has the
>right address? My nightmare was having multiple DHCP servers running
>on a LAN.

Years ago I was at a tradeshow - maybe ISPcon. An annoucment came
over the house system asking for all booth vendors to check their
machines to make sure there was no DHCP running.

The 'network provider for the convention used DHCP, and at leat 1
rogue DCHP server on the show floor was issuing IPs that went
nowhere. The 'simplicity' of DHPC can surely cause problems.
Personally I can only see it's use when you have far more machine
than available addresses and only a percentage are going to be on
line at any one time. It's my anal nature.

Bill

--
Bill Vermillion - bv @ wjv . com

On Tue, 06 Apr 2004 10:44:20 -0700, Jeff Liebermann
<jeffl@comix.santa-cruz.ca.us> wrote:

>On Tue, 06 Apr 2004 09:17:31 +1200, David Kirk
><davidrkirk.NOSPAM@hotmail.com> wrote:
>
>>All of this is happening on our local LAN. Both subnets are on the
>>same piece of wire, but of course they won't talk to each other
>>without the router. There are no WAN links or Internet involved.
>
>Now you tell me. This is what threw me:
>"The router at the default gateway (192.168.1.251) is a Cisco 1721 set
>up to pass all traffic between the two subnets."
>Lacking any info on the topology, I just assumed that you were
>routeing between two subnets over the internet. Grumble...

The first sentence in this thread was "We are migrating our network
from a 192.100.100.0 subnet to a 192.168.1.0 subnet and I am having
problems with our SCO 5.0.4 boxes.". I guess I didn't make it clear
that I wasn't moving the network, but just re-addressing it. Sorry.

>Don't forget the WINS cache, NETBIOS name cache, various HOSTS and
>LMHOSTS files, etc. Yeah, great idea. I've done it that way and
>managed to "forget" necessary changes. The problem is that everything
>had to get fixed twice. Once to get the multi-address configuration
>to play, and once again when I had to get rid of it. Is there a
>reason you can't just change everything at once? Why prolong the
>ordeal?

We are open for business 24 hours per day, 7 days per week. We only
close for Good Friday (in 2 days), ANZAC day and Christmas day. I
don't plan on breaking everything on Friday and trying to fix multiple
systems over the rest of the weekend (when I probably won't be able to
get vendor support).

>I vaguely recall that there was some kind of bug in the alias
>mechanism in 3.2v5.0.4 that was later fixed. I'll dig when I get to
>the office (timer permitting).

It seems to be working fine for me.

>>The JetDirect is still set to use DHCP. The address hasn't changed
>>since the printer was installed. When I move it to the other subnet
>>it will have a static address.
>
>Well, if it's currently set for DHCP, are you sure that it has the
>right address? My nightmare was having multiple DHCP servers running
>on a LAN. It happens almost every time someone tinkers with a
>wireless router. I have arpwatch running to detect such problems on
>mission critical networks. Lately, I've been using "static DHCP" to
>assign IP addresses to print servers. The idea is to build a table of
>MAC address and IP address pairs in the router that's running DHCP,
>and reserve the IP's for those devices. I haven't figured out an
>effective backup scheme in case the DHCP server dies, but that hasn't
>been much of a problem with long lease times.

Yep. I just checked it.

>>Unfortunately (?) I can't test it at the moment because it all works
>>and I don't know how to replicate the fault other than wait until
>>tomorrow morning :-( I can answer some of them from my previous
>>testing though.
>
>Well, if it's intermittant, then it's probably the RIP1 (routed)
>problem. That means you have a router or server on your LAN that's
>spewing RIP announcements. Find and disable. It will break other
>devices.

I have disabled routed as you suggested earlier.

>>There is only 1 router with 2 interfaces (1 for each subnet).
>
>With every IP port transparently routed between both networks?
>
>>Yes, very logical. I will have another go at this next time it fails.
>>Because it is the SCO box that is the problem though, I think I should
>>probable see what I can ping from the SCO box. Eg. localhost, another
>>host on same subnet, router local interface, router remote interface,
>>host on other subnet. That should more accurately find the fault.
>
>Yep. The pattern should be obvious. I still think there's some
>obscure file on the OSR5 boxes that haven't had their IP address
>tweaked. I know you said you checked everything, but I'm still
>suspicious.

I came in this morning, went to the server and tried to ping the
printer. It didn't respond.

I pinged another server on the 192.168.1.0 subnet and got a response.

I pinged both interfaces of the router and got responses.

I pinged other hosts on the 192.100.100.0 subnet and got responses.

I telnetted to the router and pinged the printer and got no response.

This proves the problem is not with the SCO boxes, but with the
router. Sorry to waste your time, but I learnt heaps and cleaned up a
few things on my SCO boxes.

Thanks for all your help. Now I will have to figure out what is wrong
with the router.


Later

David Kirk

"Bill Vermillion" <bv@wjv.comREMOVE> wrote in message
news:HvrnDG.1vDy@wjv.com...
> In article <2op570hbtj53svg2u11jjd7b85e86vbk1l@4ax.com>,
> Jeff Liebermann <jeffl@comix.santa-cruz.ca.us> wrote:
>
> >Well, if it's currently set for DHCP, are you sure that it has the
> >right address? My nightmare was having multiple DHCP servers running
> >on a LAN.
>
> Years ago I was at a tradeshow - maybe ISPcon. An annoucment came
> over the house system asking for all booth vendors to check their
> machines to make sure there was no DHCP running.
>
> The 'network provider for the convention used DHCP, and at leat 1
> rogue DCHP server on the show floor was issuing IPs that went
> nowhere. The 'simplicity' of DHPC can surely cause problems.
> Personally I can only see it's use when you have far more machine
> than available addresses and only a percentage are going to be on
> line at any one time. It's my anal nature.

We use static-assigned DHCP for all PC's and print-servers.

The idea being if we need to migrate to a different IP subnet (we have to
from time to time), it's fairly easy.

As we run Samba for Wins and a local DNS server, everything should be
fairly dynamic for changes.

It also means that it's easier to configure new equpitment, as you just
plug it in, and it's got an address.

bkx