Conference netcad::hub_mgnt

Oh boy, I knew this would come up eventually.  Unfortunately, the answer is not
what you want to hear.  The current implementation of IP in the DECagent
contains a two-entry router table, one for the local host and one for the
default gateway.  Therefore, subnetting is only supported from the perspective
of "if the destination IP address is not in the same subnet as the source IP
address then send it to the default gateway and let it figure it out."

Could this be dangerous?  I wouldn't say 'dangerous' so much as 'limiting' in
that it does not give the network manager the flexibility to balance network
load across multiple routers.

And to fend off the next logical question, there are no plans to implement true
subnet masking in V2.0 of the DECagent.

...Roger...

Roger,


Thanks for your answer. Maybe it will be implemented in further versions (after 
V2.0).

We already had situations, we needed this flexibility.


Roland

    I would like to re-raise this question. 
    
    As customers are installing the Dechub 900 some are acting on the
    preserve your investment message and moving the DEChub 90s to smaller
    offices. The smaller the office the more likely it will be one
    with a bitmask type of subnet mask.  
                   
    So --
    
    Has the subnet mask capability been built in to the DECagent 90 in the 
    post 2.0 firmware ? I think we are up to version 2.1.3 ? 
    
    Is there a time frame for this functionality?
    
    Jim 
                           

	Roger Gaudet referred me to this note. I'm currently the team leader
	for the next DECagent90 update. The agent is now at rev level 2.1.3,
	and the next revision will be 3.0. The primary reason for 
	the agent update is to support the new stackable repeaters, which
	introduces some new LH commands (that's the backplane serial line
	protocol) and a new hub configuration.

	I'm not an IP expert, so I had to ask around for a definition of
	the subnet mask issue. There seems to be 2 problems:

	     1. Since the user can't set the subnet mask, we automatically 
	        send traps to the default gateway (if one has been specified) 
		even if the trap address really lives on our subnet. The 
		router forwards the packet, then sends a "redirect"
		message back to us, indicating that we should be arping for 
		that address ourselves. So the router is responding to more
		requests than it needs to.

	     2. Apparently NetView uses subnet mask in a mapping algorithm.
	        Since our mask is 0.0.0.0, it breaks the algorithm.

	I don't yet know how much work it would take to add subnet mask
	capability to the agent. I will certainly put it on the list of
	Things To Look At. It will also have to be assigned a priority, 
	which most likely will be lower than support of the stackable
	repeaters.

	We have two constraints which will affect the decision to support
	subnet mask: schedule, and code space. The schedule is already 
	pretty tight (when is it not?); we go to system test in mid January.
	The code space is even tighter. The agent has just 16K of space left
	in Flash out of 256K total. Into that 16K we have to squeeze new
	versions of common code and everything needed to support new repeaters.
	We have already determined that we can't fully support the repeaters,
	so we will get what we can from the available space. This may not
	leave much left over for subnet mask support.

	The best I can tell you right now is: It's on The List.

	Regards,
	Dave

    Thank you for the quick reply.
    
    Jim