Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!aramis.rutgers.edu!geneva.rutgers.edu!hedrick From: hedrick@geneva.rutgers.edu (Charles Hedrick) Newsgroups: comp.sys.proteon Subject: Re: Problems with P4200s not updating routing tables. Message-ID: Date: 5 Jun 89 19:38:04 GMT References: <8906051737.AA29493@devvax.TN.CORNELL.EDU> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 35 1) The RIP spec. It says you *have* to poison all your routes. I can ... Proteon has no choice here--they have to follow the spec. I wrote the RFC for RIP. It is not quite so cut and dried. The RFC points out both the advantages and disadvantages of poison reverse. It requires that you implement poison reverse, but it explicitly allows you to provide an option to disable it, and it also allows a hybrid scheme, such as using poison reverse for a certain period of time after a route disappears and then dropping the route. 2) The fact that things "synch up". As Van Jacobson has demonstrated, RIP processes will end up in sync, even if they start out at random times. This is why all these packets flood What Van demonstrated is that DECnet syncs up, in certain circumstances. I had speculated that this might be a problem, and in fact a paper I wrote with Len Bosack a year or two ago mentions it. In preparing that paper I looked for evidence that it was happening on our network, and wasn't able to find any, either for DECnet or IGRP (both using cisco routers). Van's results were for DECnet, apparently using VAXes as routers. The RIP RFC was written after Van's presentation. It mentions the problem of self-synchronization explicitly, and requires that the implementation take precautions that are sufficient to prevent it. I know that the folks at Proteon are aware of this problem. I would expect them to have taken the necessary precautions. I do agree that sending the entire Internet routing table via RIP could easily overload an interface. Ballpark calculations suggest that you could be sending on the order of 20 packets. How dangerous this is depends upon how close together they are. If the packets are sent off as they are filled, there would be a bit of space between them. If they are queued at once, our experience with NFS suggests that 20 back to back packets is going to cause trouble to many different kinds of interface.