[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference netcad::hub_mgnt

Title:DEChub/HUBwatch/PROBEwatch CONFERENCE
Notice:Firmware -2, Doc -3, Power -4, HW kits -5, firm load -6&7
Moderator:NETCAD::COLELLADT
Created:Wed Nov 13 1991
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:4455
Total number of notes:16761

628.0. "Using Different Subnet Masks" by PANIC::DUNOYER (Una Du Noyer, SWAS Central London) Mon Jan 17 1994 10:32

    Hi
    
    I am working on a project where we are going to use a configuration
    consisting of DEChub 900s, Gigaswitch, and DECnis. We have a Class B
    network address, and will use a subnet mask of 255.255.252.0 to allow
    for over 1000 host addresses without routing.
    
    The DEChub management IP address can be assigned, but not the
    subnet mask. I understand (from Nice Network Academy) that the Hub
    works out its subnet mask from the network number i.e. it knows if it's
    a Class A, B or C and assigns the mask automatically. There is no way
    of manually entering the subnet mask.
    
    In our case then, with a Class B address, I assume the Hub will default to 
    255.255.255.0. Is this the case ? Is there any way we can assign it a
    subnet mask of 255.255.252 ? 
    
    Thanks for any advice.
    
    Una
T.RTitleUserPersonal
Name
DateLines
628.1Why a subnet mask isn't needed.QUIVER::GALLAGHERMon Jan 17 1994 13:0467
An old mail message on the subject, "Why don't we need a subnet mask?"


From:	LEVERS::KRISHNA      "Krishna Narayanaswamy TAY2-2/B4 227-3572" 10-FEB-1993 11:02:48.34
To:	LEVERS::GALVIN
CC:	ANIL,QUIVER::GALLAGHER,HISCOCK,KRISHNA
Subj:	RE: Subnet mask issue...Can you help ??  THANKS!

Cheryl,
    I have given below an explanation as to why we really don't need subnet
masks on our SNMP agents. I have taken the scenario in which the SNMP agent is
on one subnet and the NMS is on a different subnet and the two are connected
through routers. The only need for subnet mask arises when you need to talk to
NMS's which are not on your subnet (i.e you are separated from the NMS by
routers). Given an NMS's IP address you can use the subnet mask and figure out
if the NMS is on your own subnet or not. If the NMS is not on your own subnet
you should lookup your routing table to figure out which router you need to
send your message so that it reaches the NMS. But our IP satck design 
circumvents this problem as I have explained below



     +-------+  Subnet 1 +********+ Subnet 2  +#######+
     | Agent |-----------| Router |-----------| NMS   |
     +-------+           +********+           +#######+

1) SNMP request when received by the Agent has the following details.

    Dest DataLink Address  = Agent's Ethernet Address
    Src  Datalink Address  = Router's port 1 Ethernet address

    Dest IP address        = Agent's IP address
    Src  IP address        = NMS's IP address

When the agent processes the request it updates its ARP cache to contain the
following:
      IP Address         Hardware Address                  Port #
      ----------         ----------------                  ------
    NMS's IP Address      Router's port 1 ethernet address   1

So when it comes time to reply to the SNMP request, the ARP cache is looked up 
and the message is sent out to the Router and it then forwards the reply to
the NMS.

The only sticky case comes when there is more than one router through which you
can reach the NMS and the router chosen when the request came in is not the
one which provides an optimal path for the reply. In this case we will send the
message to the router through which we received the request and it is the rtr's
responsibilty to notify us through an ICMP redirect message telling us
in future to use a different router to talk to the NMS, but the router is still
required to forward this message to the NMS though it is not the optimal path.

Once we receive the ICMP redirect message, we register it in our ARP cache and
use it in future to talk to the NMS, until the ARP entry ages out. So we really
don't need subnet masks to talk to NMS's which are not in our own subnet.

I have used HP Openview, NetLabs Netmanager in the UNH interoperability lab to
manage our DECbridges through SNMP and in this case the NMS's spoke through 
routers to our bridges, so I know that it works.

As far as the other question :

      2) Can you define a default router/gateway on the DECagent 90?

I know on the Bridge/Concentrator you can set it. Not sure about DECagent 90.

Krishna
628.2To address point #2QUIVER::GAUDETMon Jan 17 1994 14:275
    .1>>   2) Can you define a default router/gateway on the DECagent 90?

    Yes, you can through the console interface (DECagent V1.1 and later).
    
    ...Roger...
628.3QUIVER::SLAWRENCEMon Jan 17 1994 16:169
    On the IP Server you can configure a default gateway address and that's
    all we really need.  
    
    Using the subnet mask to compute whether or not an address is on your
    own subnet is an optimization that can be skipped.
    
    At least one version of the DECagent90 code did compute subnet mask
    from the network number, but future versions will not - they use the
    same simplification that is described in .1
628.4LEVERS::ANILMon Jan 17 1994 20:309
    Default gateways are needed only for unsolicited traffic originated
    by a hub900 module.  The only example of such traffic is SNMP traps.
    So you don't even need to configure a default gateway before starting
    to use IP-based protocols including SNMP (responses), TFTP, pings.
    (As an aside: SNMP traps are unacknowledged, so not guaranteed to
    reach the manager.. as such, they are considered of limited use.
    Polling is the norm for reliable monitoring in SNMP.)
    
    Anil