lane@DUPHY4.Drexel.Edu (Charles Lane) (01/17/89)
I've noticed that our mailer is getting a number of SYN
packets directed at it (~2/hr...from west coast hosts)
that it can never seem to ACK and get a connection going.
The sequence of events is like this (Us = 129.25.1.103, port 25, SMTP;
Them = CRVAX.SRI.COM)
Them: SYN SMTP server process starts, and:
Us: ACK SYN
.... about 1 min later ...
Them: SYN (duplicate)
Us: ACK SYN
this repeats (retransmitted SYNs in, retransmitted ACK SYNs out)
until finally one (or both) get fed up and time out.
The best explanation that I can come up with is that the ACK SYN's
aren't getting back to CRVAX. Could this be a routing problem?
We've observed this behaviour with a number of hosts, and the best
explanation we've thought of so far is that the packets are coming in
over a `good' route and going out over a `bad' route.
I'd appreciate any comments or suggestions.
--Charles Lane
lane@duphy4.drexel.edu
cel@cithex.caltech.edu
lane@duphy1.bitnetTYSON@SRI-NIC.ARPA (Mabry Tyson) (01/18/89)
>Date: Mon, 16 Jan 89 13:50:41 EST >From: lane (Charles Lane) @ DUPHY4.Drexel.Edu >Subject: SYNs that don't get ACKed >To: tcp-ip @ DUPHY4.Drexel.Edu >The best explanation that I can come up with is that the ACK SYN's >aren't getting back to CRVAX. Could this be a routing problem? >We've observed this behaviour with a number of hosts, and the best >explanation we've thought of so far is that the packets are coming in >over a `good' route and going out over a `bad' route. [Note, while I am at SRI, I don't have any control or direct access to CRVAX.SRI.COM or SRI-GW.ARPA.] I looked into the problem of connecting between SRINET and DREXEL today. From IU.AI.SRI.COM (on the Arpanet directly), I could ping 129.25.1.103. The response time was on the order of 1 to 4 seconds. I set up another host (that is on SRINET) to go through the same gateway that CRVAX.SRI.COM uses (SRI-GW.ARPA). When I tried to ping from there, I couldn't get through (and got a message from SRI-GW indicating that destination was an unreachable network). From IU, I found out that it was going through JVNCA.CSC.ORG to get to DREXEL. That immediately set off alarms for me as we had routing problems to RUTGERS behind the same gateway a week or so earlier. As I recall, on one day, our EGP info was that we should use JVNCB.CSC.ORG to get to Rutgers but we couldn't get through. If we changed it to route through JVNCA, we got through. (On the previous day, the problem was exactly reversed: EGP told us to use JVNCA but packets to it didn't work while JVNCB did work.) At that time, JVNCB had an arpanet address (according to domain info) of 10.18.0.16. Now when I look up that host, it no longer shows an Arpanet address. I don't know what route SRI-GW.ARPA is using to get to DREXEL. Maybe it, or the gateway it routes to still, thinks it should try JVNCB.CSC.ORG (on the old(?) Arpanet address)??? I suspect the situation with the JVNCnet is in flux and you should be patient with it for awhile. P.S. FYI: The network configuration at SRI will be changing beginning on Feb. 11. I think SRI-NIC.ARPA will be basically unaffected but network connectivity to all other hosts at SRI may encounter problems. SRI will be available through BARRNET (part of NSFNet) when the Arpanet dies (which looks like it will be sooner than I think it should be!) but it isn't yet set up. -------
lear@NET.BIO.NET (Eliot Lear) (01/19/89)
Yes, since around December, 10.18.0.16 has been a black hole for packets. Looking at my ARPANET routing tables even now, I see that it is still my only ARPANET route to Rutgers. One problem that I believe we faced was the instability of this gateway, or so it seemed. Regarding what JVNCB is, I know JVNCB to be a Vax. When I telnet to 10.18.0.16, I get connected to a Cisco box. As of today, I also see that the host information agrees with me. -- Eliot Lear [lear@net.bio.net]
cire@CISCO.COM (cire|eric) (01/19/89)
There was a slight communications problem. Seems that a change was requested that caused a name to change instead of addresses changing. So what happened was there were two nodes that had the address 10.18.0.16, JVNCB.CSC.ORG and FORD.CSC.ORG. The later is a cisco box that indeed is connected to the ARPAnet. I know all of this because Bob A. from JVNC was out today visiting cisco and we happened to talk about it. He is working with the appropriate people to get this fixed. -c cire|eric Eric B. Decker cisco Systems Menlo Park, California email: cire@cisco.com uSnail: 1360 Willow Rd., Menlo Park, CA 94025 Phone : (415) 326-1941