|
From: <st...@ch...> - 2008-08-14 13:59:52
|
Hi, On Thu, Aug 14, 2008 at 02:56:35PM +0100, Mik...@co... wrote: > > > Hello, > > I'm not sure if this is a specific problem with PDP11s > or just how ours our setup, but have been having trouble with following:- > > > I've set up a three node network, > with 2 Charon-11 PDP11 emulations > > PDPONE 1.1 > PDPTWO 1.2 > > > and one Linux box (Kubuntu dapper, using 2.43 version of dnprogs) > > LINONE 1.3 > > > Both PDP11 nodes access the Linux node, without any problem > But I couldn't get Linux node to always access the PDP11 nodes > Sometimes they worked, but most of the time dnping or dndir seemed to > trigger dnetd. > > > After some fiddling around, > I found that if first action after booting linux box is to try and > communicate from linux node to PDP11 node, > then Linux node thinks that PDP11 nodes are local, > If first action is to access linux box from a PDP11 node > then Linux node sees that PDP11 nodes are on network > > > ie; following output from 'dnetinfo' > > i) straight after reboot > > Addr Dev > 1.3 LINONE lo > > > ii) after accessing LINONE from PDPONE > > > Addr Dev > 1.3 LINONE lo > 1.1 PDPONE eth1 > > - Once in this state, everything works ok > > > iii) After reobot and first access is from LINONE to PDPONE > > Addr LINONE Dev > 1.1 PDPONE lo > 1.3 LINONE lo > > > - In this state all access from LINONE to PDPONE is seen as local and sent > to dnetd or fal > (which then keep forking themselves) > > > > iv) As iii) after accessing LINONE from PDPONE > > Addr LINONE Dev > 1.1 PDPONE lo > 1.1 PDPONE eth1 > 1.3 LINONE lo > > Subsequent behaviour is as iii) PDPONE can communicate with LINONE, > but LINONE wont access PDPONE > > > > > > I found reference on project site in faq-4 to similar sounding problem > (4.1 Phase v nodes disappearing) > and the suggestion of setting static route cures the problem > > > ie; > ip -f dnet neigh add 1.1 dev eth1 > ip -f dnet neigh add 1.2 dev eth1 > > > This seems straight forward enough, but I was wondering if there's > something I've missed, > with configuration causing the problem. > > Thanks. > > I suspect thats down to whether or not the Linux node has seen any hello messages from the remote node. If not then it doesn't know where to send packets for that node. Btw, those are not static routes you are adding, but neigh table entries. If you did add a route then, if my memory doesn't fail me it should also solve the problem. Part of the problem is due to the way that the timeouts occur. We should time out the neigh entries according to the time specified in the hello messages. We don't do that only because of the implementation of the neigh table which makes it impossible to set different timeouts for each entry. Something that perhaps needs fixing one of these days, Steve. |
