|
From: Colin B. <col...@xd...> - 2003-02-22 10:15:40
|
My background is DECnet Phase IV & V, predominantly VMS, not Linux, so I can't comment on any of the Linux specific stuff. It looks to me as if there isn't enough understanding of how to configure / manage / use DECnet at the VMS end. <snip> >> I have seen problems in the past with Phase V not sending regular enough >> hello messages to keep an entry in the neighbour table. This can be fixed >> by forcing the information into the table with iproute2. > > Sure, but wouldn't I eventually see a hello? Anyway, I tried playing > with iproute2 but I'm not sure if I have the necessary stuff in my > kernel to support it. Will look into this and recompile kernel if > necessary. It depends what the "hello timer" is set to. Your code should cope with anything between the minimum and maximum values - you may need to see the published (not sure where they are on the web now) functional specifications, however you should be able to determine these by using NCP (Phase IV) or NCL (phase V) on a test node. Note that there are hello timers for L1 routers to other L1 routers and for L1 routers to End Nodes (Phase IV terminology) or IS to IS and IS to ES (Phase V terminology). Phase IV default is 30 secs, Phase V default is 600 secs. I usually change these to be more useful for a specific network, along with other things such as retransmit factor. See the published DECnet on VMS manuals at http://www.openvms.compaq.com/doc/ and find DECnet way down the left hand side - the various parameters you can configure haven't changed for some time. There's also some Phase IV and Phase V notes at www.xdelta.co.uk/downloads/decus which are things I've done for the HP User Group over the years. > > Might well do. I wonder if there isn't some filtering on the network > > affecting the hello messages. Not that this should prevent you from > > setting up a connction with 1.1, it would only explain the lack of an > > automatically generated entry in the neighbour table. > > Since I'm just toying around to see if I can get this working, getting i> nformation about what filtering, if any, might be in place on the > switches may prove to be difficult to extract from the net admins. It's > not that they're unreasonable people, but it's very difficult to get any > of their time. Layer 2 (MAC address / protocol type etc.) filtering usually only comes in if you've got bridges set up with filtering enabled, or bridge filtering between VLANS or whatever set up in core switches. That's NOT a default configuration, so requires thought and planning to set it up. Don't even think of going there and making / suggesting changes unless you understand it! It's easy enough to see if filtering is happening - just use a network analyser (packet sniffer or whatever - even the M$ network monitor from their SMS product will be useful enough) and look for all the DECnet related packets and sort out what's what based on the MAC addresses in the "destination" field. You should see multicast addresses on packets which correspond to the Phase IV and Phase V L1 and End Node hellos etc. See RFC1700 for all the address and protocol type details at http://www.faqs.org/rfcs/rfc1700.html. DECnet Phase IV is protocol type 60-03, Phase IV end node hello multicast address is AB-00-00-03-00-00, Phase IV router hello is AB-00-00-04-00-00. Phase V in Phase IV compatible addressing mode (which is what most people use) will do all the Phase IV hello stuff and use Phase IV MAC addressing for the ethernet packets. I'm currently trying to write a reasonable definitive article on "DECnet, a Technical Overview" for the VMS Technical Journal, so look there in a couple of months if you're interested - http://www.openvms.compaq.com/openvms/journal/index.html |
