hedrick@athos.rutgers.edu (Charles Hedrick) (07/18/88)
I propose to write an IDEA suggesting a set of variables for the MIB to monitor DECnet phase IV implementations. At first glance it seems slightly batty to have an Internet standard for DECnet. But there are several vendors that support IP and DECnet. We'd like to be able to monitor DECnet performance using SG/NMP, since our gateway monitoring is all done via IP. I'd rather do this via a multi-lateral name space than to ask cisco to do it as a private one, for obvious reasons. This note lists the variables that one could reasonably get from the cisco DECnet implementation. I have put stars beside the ones that I think are important for network monitoring. I'd appreciate responses from others who have similar needs. I'd particularly appreciate a list of the data that Proteon currently collects about DECnet, whether it is available via SGMP or not. Note that I haven't starred the routing table, because I'm not quite sure what I'd use it for. However I have a feeling others will probably want it. configuration parameters: * decnet is running: boolean * address: two integers (actually a 16-bit number, but for humans it is better to think of it as two shorts) * node type: enumeration: endnode, router, area router max address: integer max area: integer routing timer: integer, in seconds (DEC has two of these, one for Ethernet and one for point to point lines. I don't make the distinction, but could easily return the same value for both.) hello timer: integer, in seconds (It's possible that there are also supposed to be two of these. I'd have to check.) max cost: integer max hops: integer area max cost: integer area max hops: integer max visits: integer * router priority: integer interface parameters: interface identifier: ?? in the text output I use device names, such as "ethernet 0". Should this be given? Probably we should guarantee that the interface indices are the same for IP and DECnet. Thus you can check the corresponding IP if counts for counts like bad packets, and for other static if information * decnet enabled on interface: Boolean * we are the designated router for this interface: Boolean * cost: integer (this is routing metric cost for traversing that interface) area routes: table indexed by area number hop count: integer cost: integer next gateway: two integers (DECnet address) interface: ?? we must define how the local area shows. The obvious things to do are to omit it, or to give 0 hops and cost, with your own DECnet address. in-area routes: same, except table is indexed by DECnet host address. Entry 0 is the nearest area router, which is the local address with 0 hops and counts if this box is an area router. if the host is on a directly connected network, the next gateway is the host itself. We keep some additional information. I suspect we don't want to complicate SGMP by including it: router priority of this guy, number of seconds until hello expires. statistics (all integers): * total received * format errors unimplemented control messages not a gateway (messages for somebody else that we can't do anything about) * no memory no routing vector (this is not expected to happen. It means that we didn't yet have some of the data structures set up, in effect that we hadn't received any routing broadcasts yet. You get a couple at startup and that's it.) hellos received * bad hellos hellos for other area ignored hellos sent level 1 routing received * bad level 1 routing pkt level 1 routing for other area ignored level 1 routing sent level 2 routing received level 2 routing sent * [hmmm... no bad level 2 routing? Probably should be there even if I always report 0] * data received * data bad format * data too many visits * data no route to destination data encapsulation failed [shouldn't happen: indicates we had a route in the routing table, but somehow the lower-level routines couldn't figure out what to do with it.] * data forwarded correctly