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)