oconnor@SCCGATE.SCC.COM (Michael J. O'Connor) (12/17/87)
Andy, First of all, I never received the message I'm replying to. When Enger asked me about the patch a few minutes ago, I asked him to forward his copy. As for the results of the patch, they looked mixed from our point of view. Our first retest, using good old twg.arpa, produced the following output fron Sun's X25 management software: x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED x25manager: std LCN 0 from 10.4.0.51 REMOVED VC has timed out x25manager: std LCN 3 from 10.4.0.51 ADDED Sun's support organization tells me that the "REMOVED VC" message is printed when the PSN times the circuit out. As opposed to the "Removed Normal Timeout" message printed when the Sun software times out the circuit. Meanwhile the following was being output by ping: ping -v twg.arpa PING twg.arpa: 56 data bytes 64 bytes from 1a050049: icmp_seq=1. time=2499. ms 64 bytes from 1a050049: icmp_seq=3. time=3160. ms 64 bytes from 1a050049: icmp_seq=7. time=1480. ms 64 bytes from 1a050049: icmp_seq=10. time=1300. ms 10 packets transmitted ----twg.arpa PING Statistics---- 10 packets transmitted, 4 packets received, 60% packet loss round-trip (ms) min/avg/max = 1300/2109/3160 Every time the virtual circuit was added, I received a packet from twg.arpa via 10.4.0.51 (add the circuit 4 times, get 4 packets). We ran this test a couple of times with similar results (different packet counts and sequence numbers got through). If I pinged 10.4.0.51 the problem went away as reported previously. [7] ping -v 10.4.0.51 PING 10.4.0.51: 56 data bytes 64 bytes from a040033: icmp_seq=3. time=1880. ms 64 bytes from a040033: icmp_seq=4. time=1340. ms 64 bytes from a040033: icmp_seq=5. time=1180. ms ^C ----10.4.0.51 PING Statistics---- 7 packets transmitted, 3 packets received, 57% packet loss round-trip (ms) min/avg/max = 1180/1466/1880 [8] ping -v twg.arpa PING twg.arpa: 56 data bytes 64 bytes from 1a050049: icmp_seq=2. time=2220. ms 64 bytes from 1a050049: icmp_seq=3. time=1660. ms 64 bytes from 1a050049: icmp_seq=4. time=1520. ms 64 bytes from 1a050049: icmp_seq=5. time=2340. ms 64 bytes from 1a050049: icmp_seq=6. time=1940. ms 64 bytes from 1a050049: icmp_seq=7. time=1300. ms 64 bytes from 1a050049: icmp_seq=8. time=1140. ms 64 bytes from 1a050049: icmp_seq=9. time=1180. ms 64 bytes from 1a050049: icmp_seq=10. time=2219. ms ----twg.arpa PING Statistics---- 10 packets transmitted, 9 packets received, 10% packet loss round-trip (ms) min/avg/max = 1140/1724/2340 As I type this message I can see other Virtual circuits thrashing. I assume that whatever service they are trying to perform (SMTP, FTP) it is being accomplished 1 packet per add/remove cycle, if at all. I'm left with the impression that the patch simply lowered the PSN virtual circuit timeout value in an attempt to take advantage of the earlier observation that a packet would come through on each PSN==>Host VC setup. So yes, I believe the problem still exists, although in a mutated form. Additionally, if not this circuit thrashing, something is confusing the hell out our X25 circuit management software. Twice today the manager hung up, refusing to create outbound circuits or accept inbound ones. The program had to be manually stopped and restarted. Sun support tells me that their gateway works so I should contact BBN. It was previously suggested by BBN that I should be kvetching to Sun. What's a poor user to do? Mike ps: Bob asked me to mention that not only did I not receive the message, it took 10+ hours for him to receive his copy.