| 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 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
|