fedor@DEVVAX.TN.CORNELL.EDU (Mark Fedor) (09/21/87)
Hi people. Recently here at cornell we have been experiencing a number of strange routing problems. Routes on certain vaxen gateways were being mysteriously timed out, while other dedicated gateway boxes seemed fine. Here at Cornell, we use RIP and everything is dynamic. We have Proteon P4200's and vaxen running gated/routed for gateways. Our ARPAnet gateway, CU-ARPA was one of the victims of this problem. CU-ARPA is a vax750 with 2 DEUNA's and one Pronet-10 interface. CU-ARPA also has an ARPAnet interface. After pulling my hair out and checking the routing software, I noticed that our vax was experiencing RIP congestion and couldn't keep up with all the RIPpers on its networks. On its Pronet 10 interface we have approx 11 RIPpers. On 1 of its Ethernet interfaces we have approx 7 RIPpers. on the other Ethernet interface we have 2 RIPpers. Plus, since we have a large number of networks being RIPped around, each gateway sends out 3 RIP packets for a complete update. The routing process opens one socket and listens on the RIP port. If I read the UDP code right, each socket allocates space for 4k of datagrams. CU-ARPA is easily dropping RIP packets left and right. Has anyone else experienced this? Any suggestions? I suppose I could increase "udp_recvspace" in netinet/udp_usrreq.c, but that would only prolong the agony. I know, I know, get a real machine for a gateway..... :^) Thanks. Mark P.S. Not suprisingly, the Proteon P4200 is having no problems.
sklower@RENOIR.BERKELEY.EDU (Keith Sklower) (09/22/87)
In his message of Mon, 21 Sep 87 16:32:08 -0400, Mark Fedor <fedor@devvax.tn.cornell.edu> writes: : The routing process opens one socket and listens on the : RIP port. If I read the UDP code right, each socket : allocates space for 4k of datagrams. CU-ARPA is : easily dropping RIP packets left and right. : : Has anyone else experienced this? Any suggestions? I suppose : I could increase "udp_recvspace" in netinet/udp_usrreq.c, : but that would only prolong the agony. In fact, this has been noticed here at Berkeley as well. It is possible in 4.3 unix to increase the buffering for a particular datagram socket, and the current version of routed has been changed to do that to circumvent this problem. (There have been other changes since 4.3, but Mike Karels is traveling, and will not be able to supply a definitive statement about which are worth incorporating until his return). In the meantime, you can apply this patch to routed/main.c: *** main.c.fix Mon Sep 21 18:22:13 1987 --- main.c Mon Sep 21 18:19:11 1987 *************** *** 186,195 **** close(s); return (-1); } - on = 48*1024; - if (setsockopt(s, SOL_SOCKET, SO_RCVBUF, &on, sizeof (on)) < 0) - syslog(LOG_ERR, "setsockopt SO_RCVBUF: %m"); - if (bind(s, sin, sizeof (*sin), 0) < 0) { perror("bind"); syslog(LOG_ERR, "bind: %m"); --- 186,191 ----