[comp.sys.sun] SUNOS 3.4 problem

roes@seri.philips.nl (Aloys Roes) (01/30/90)

We ran into a problem with TCP/IP on SUNOS 3.4. A number of these systems
can no longer communicate to the outside world. This problem suddenly
popped up last week. None of the system administrators have changed
anything relevant lately (they say). 

The configuration is as follows:


               outside world i.e.:
                   network 130.143.0.0
                   network 130.145.0.0 etc ...
                   subnet 130.144.60.0
                   subnet 130.144.61.0 etc ...                  |
                       \  |  /                    |-------+-----+----|
                        \ | /                             |
                      +---+---+           +-------+   +---+---+
                      | cisco |           | Other |   | Other |
                      | router|           |Systems|   |routers|
                      +---+---+           +---+---+   +---+---+
                          | 254               | ...       | ...
      |-------------------+---------+---------+-----------+------|
        130.144.1.x             ie1 | 115
                                +---+---+
                                | Sun A |
                                |  3.4  |
                                +---+---+
              130.144.20.x      ie0 | 99
		|-------+-----------+--------------+---------|
                    ie0 | 101                  ie0 | 102
                    +---+---+                  +---+---+
                    | Sun B |                  | Sun C |
                    | 4.0.3 |                  |  3.4  |
                    +-------+                  +-------+

The subnet mask for all systems is set to 255.255.255.0.

The problem is that the Sun A and C (both SUNOS 3.4) cannot communicate to
systems in their own network but different subnet meaning that it does not
take the correct decision on whether to use ARP or routing. e.g SUN A can
send ICMP echo requests and receives replies from hosts in subnet
130.144.1 and 130.144.20. Also PING to hosts in network 130.145 and
130.143 works fine.  However when a PING request is made to a host in a
remote subnet e.g.  host 130.144.60.80, the SUN does not send the packet
to the cisco router but does an ARP request on the ethernet with interface
ie0 instead.  Strangely enough a PING from host 130.144.60.80 gets a reply
when sent to 130.144.1.115 but not when sent to 130.144.20.99. 

SUN A has 'routed' running and the routing tables look ok. Rebooting makes
no difference. Adding a default gateway also shows no result.  Only
netstat -i does not show subnets but has never done that under SUNOS 3.4. 

Does anyone have suggestions. Any comment will be appreciated.

Thanks in advance,

Aloys Roes, Philips Components, Building BC-136, |  Tel. : + 31 40 72 30 62
P.O.Box 218, 5600 MD Eindhoven, The Netherlands  |  Email: roes@seri.philips.nl

iand@labtam.oz.au (Ian Donaldson) (02/08/90)

roes@seri.philips.nl (Aloys Roes) writes:
>The problem is that the Sun A and C (both SUNOS 3.4) cannot communicate to
>systems in their own network but different subnet meaning that it does not
>take the correct decision on whether to use ARP or routing. e.g SUN A can
>send ICMP echo requests and receives replies from hosts in subnet
>130.144.1 and 130.144.20. Also PING to hosts in network 130.145 and
>130.143 works fine.  However when a PING request is made to a host in a
>remote subnet e.g.  host 130.144.60.80, the SUN does not send the packet
>to the cisco router but does an ARP request on the ethernet with interface
>ie0 instead.  Strangely enough a PING from host 130.144.60.80 gets a reply
>when sent to 130.144.1.115 but not when sent to 130.144.20.99. 

We had a network of Wellfleet routers and Suns set up at RMIT and found
that the SunOS 3.5 ping command didn't obey normal routing rules.  

It was possible to telnet/rlogin to various hosts but it wasn't possible
to ping them.   The network was using class-B addresses subnetted with
255.255.255.0.  pinging hosts on the same subnet worked, but pinging to
another subnet failed.  Pinginging to another network worked ok.

It appeared that the ping command didn't process subnet information
properly (or something).

We solved the problem by turning on proxy-ARP on the Wellfleet routers.
(you shouldn't -need- to do this, but we had to anyway due to running
other machines on the net which didn't understand subnetting)

Ian D

nraoaoc@jupiter.nmt.edu (NRAO Array Operations Center) (02/16/90)

In article <4828@brazos.Rice.edu> iand@labtam.oz.au (Ian Donaldson) writes:
>X-Sun-Spots-Digest: Volume 9, Issue 33, message 6
>
>We had a network of Wellfleet routers and Suns set up at RMIT and found
>that the SunOS 3.5 ping command didn't obey normal routing rules.  

SunOS 3.5 had a buggy ping. There was a patch for the problem, but it
could only be used on servers and standalone systems, i.e. not diskless
clients running ND (at least, the patch we got).

Vastly improved subnet support was added in 4.0[.x]. If you (the original
poster running 3.4 and different subnets on the same wire) don't have any
software holding you back (e.g. drivers for non-Sun devices) it would be a
good idea to upgrade if you are running complex subnetting.

Ruth Milner                                       NRAO/VLA, Socorro NM

   I am posting from a shared guest account. Please send mail only to:
                 rmilner@cholla.aoc.nrao.edu  (Internet)