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

Conference noted::netview

Title:TME 10 NetView and related productscts
Notice:Bugs-12; Kits-9; ECOs-20
Moderator:TUXEDO::MINTZLL
Created:Tue Aug 24 1993
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2257
Total number of notes:7838

2232.0. "Autodiscovery creates a subnet with noname" by ZAPATA::DALLAVO (G.Alfredo Dall'Avo NSIS-Milan Italy) Mon Apr 14 1997 08:12

	The customer configuration is DUNIX V40b + PNV V41b.
	The PNV server and its clients are on the same subnet with
	subnet mask 255.255.252.0 .

	They see the rest of the network by a firewall.

	The autodiscovery create a subnet symbol without label.

	If you open the submap correlated to it you find a collection
	of nodes belonging to different subnets. If you execute a
	"pnv_smi automapgen" you get a different collection of nodes.

	Obviously if you try to access the record describing the object
	related with that subnet symbol PNV GUI crashes.

	I noticed that the autodiscovery process can't get the subnet
	mask of the management station on wich is runnin the PNV server.
	In fact if I do "ovobjprint -s pnv_server" I get 

		.....
		....

	151	TopM Interface List	"172.22.171.212 Up 172.22.171.212
<Unknown>	0xAA0004005024 other

		....

	and if I do "nmdemandpoll pnv_server" I get

	....
	...

	date	Get ARP table for discovering secondary interfaces
	date	  SNMP response error:  expect ASN type 64, received ASN type 4

	...
	
	date	Get ARP table
	date	  SNMP response error:  expect ASN type 64, received ASN type 4

	...

	It seems to me that this strange behaviour is generated by a wrong
	interaction between PNV and the local SNMP agent.

	Anyone can help me?

	Thankyou



	Gian Alfredo Dall'Avo
T.RTitleUserPersonal
Name
DateLines
2232.1ZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyTue Apr 15 1997 05:5617
	I forgot to say that I did some other tests.

	1. Not only the PNV server has problems about the autotopology:
	   All the DUNIX V4,0B nodes give the same error to the nmdemandpoll
	   and have <Unknown> for the net mask into the object database.

	2. I copyed the SNMP agent shipped with DUNIX V3.2C (/usr/sbin/snmpd)
	   on a DUNIX V4.0B system and I did a /sbin/init.d/snmpd stop + start.
	   After that Netview managed correctly that node.
	   I did the same on the PNV server and I did "pnv_smi automapgen". 
	   Obviously the PNV clients can't connect to the server, but the
	   important news is that nothing changed about the PNV server 
	   net mask into the object database and about the subnet with noname.


	Gian Alfredo
2232.2SMURF::DANIELETue Apr 15 1997 08:455
Someone will need to tell me exactly what MIB variables
are being polled, for me to help with the agent side of
things.

Mike
2232.3trace of netmon requestsZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyTue Apr 15 1997 13:11110
	Mike,

	thank you for the cooperation.

	I modified the ovsuf file in order to abilitate the trace mask
	of netmon process (8+4=12  =  SNMP requests + replies).
	Then I did "pnv_smi automapgen".

	Here is the trace:


/usr/OV/bin/nmcheckconf: ERROR: LAN interface "sl0*" not UP and RUNNING.

/usr/OV/bin/nmcheckconf: ERROR: LAN interface "ppp0*" not UP and RUNNING.
-----------------------------------------------------------------
Fri Apr 11 15:08:50 MET DST 1997
Note: default gateway not configured.  You should ensure
that your network configuration does not require a default gateway.
**** Warnings from /usr/OV/bin/nmcheckconf configuration check script
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = Objid reqid = 1159
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Objid reqid = 1159
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = Descr reqid = 1160
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Descr reqid = 1160
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = Forward reqid = 1161
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Forward reqid = 1161
15:08:50 :### IpFowarding = 2
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IPaddr reqid = 1162
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IPaddr reqid = 1162
15:08:50 :### ipAdEntAddr = 127.0.0.1, ipAdEntNetMask = 255.0.0.0,
ipAdEntIfIndex = 3
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IPaddr reqid = 1163
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IPaddr reqid = 1163
15:08:50 :### ipAdEntAddr = 172.22.171.212, ipAdEntNetMask = 255.255.252.0,
ipAdEntIfIndex = 1
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IPaddr reqid = 1164
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IPaddr reqid = 1164
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFnumber reqid = 1165
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFnumber reqid = 1165
15:08:50 :### ifNumber = 4 
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFtab reqid = 1166
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFtab reqid = 1166
15:08:50 :### ifIndex = 1, ifPhysAddress = 0xAA0004005024, iftype = 6
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFtab reqid = 1167
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFtab reqid = 1167
15:08:50 :### ifIndex = 2, ifPhysAddress = <none>, iftype = 28
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFtab reqid = 1168
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFtab reqid = 1168
15:08:50 :### ifIndex = 3, ifPhysAddress = <none>, iftype = 24
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFtab reqid = 1169
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFtab reqid = 1169
15:08:50 :### ifIndex = 4, ifPhysAddress = <none>, iftype = 23
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = IFtab reqid = 1170
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = IFtab reqid = 1170
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = GetSecIF reqid = 1171
15:08:50 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = GetSecIF reqid = 1171
15:08:50 :sending SNMP to 172.22.171.212 op = INIT req = RouteD reqid = 1172
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = RouteD reqid = 1172
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = RouteD reqid = 1172
15:08:51 :### ipRouteIfIndex = 2, ipRouteNextHop = 127.0.0.1, ipRouteType = 3,
ipRouteMask = 0.0.0.0 
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = Loc reqid = 1173
15:08:51 :*** recv_snmp: No matching reqid = 1172
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Loc reqid = 1173
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = Contact reqid = 1174
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Contact reqid = 1174
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = GetSGVers reqid = 1175
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = GetSGVers reqid = 1175
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = GetSIAVers reqid = 1176
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = GetSIAVers reqid = 1176
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = Get Mgr reqid = 1177
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Get Mgr reqid = 1177
15:08:51 :sending SNMP to 172.22.171.212 op = INIT req = Get SIAOS2 reqid = 1178
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = INIT
req = Get SIAOS2 reqid = 1178
15:08:51 :sending SNMP to 172.22.171.212 op = AT req = ARP reqid = 1179
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = AT req
= ARP reqid = 1179
15:08:51 :sending SNMP to 172.22.171.212 op = AT req = RouteD reqid = 1180
15:08:51 :recv_snmp: from nepoly.tecno.snam.eni.it (172.22.171.212) op = AT req
= RouteD reqid = 1180
15:08:51 :### ipRouteIfIndex = 2, ipRouteNextHop = 127.0.0.1, ipRouteType = 3,
ipRouteMask = 0.0.0.0 
15:11:29 :Netmon exiting by command from PMD.

================================================================================

	I hope that's what you need to help the customer.


	Gian Alfredo	
2232.4snmpget commandMOLAR::SIEGELMS: ZKO1-3/H18 DTN: 381-0035Tue Apr 15 1997 17:147
    
    Try:
    
       snmpget -c public nodename .1.3.6.1.2.1.1.1.0
    
    Joanna
    
2232.5some logsZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyWed Apr 16 1997 07:21111

/> snmpget nepoly.tecno.snam.eni.it .1.3.6.1.2.1.1.1.0
system.sysDescr.0 : DISPLAY STRING- (ascii):  nepoly.tecno.snam.eni.it
AlphaServer 2100 5/250 Digita
l UNIX V4.0B  (Rev. 564); Mon Jan 20 14:20:53 MET 1997
 TCP/IP


/> ovobjprint -s nepoly.tecno.snam.eni.it
                OBJECTID                SELECTION NAME


OBJECT: 516

        FIELD ID        FIELD NAME                      FIELD VALUE
        10              Selection Name                 
"nepoly.tecno.snam.eni.it"
        11              IP Hostname                    
"nepoly.tecno.snam.eni.it"
        14              OVW Maps Exists                 1
        15              OVW Maps Managed                1
        17              SNMPAgent                       DEC OSF Station(88)
        18              vendor                          DEC(10)
        76              isNode                          TRUE
        78              isComputer                      TRUE
        79              isConnector                     FALSE
        80              isBridge                        FALSE
        81              isRouter                        FALSE
        82              isHub                           FALSE
        85              isWorkstation                   TRUE
        100             isIP                            TRUE
        120             isSNMPSupported                 TRUE
        122             SNMP sysDescr                  
"nepoly.tecno.snam.eni.it AlphaServer 2100 5
/250 Digital UNIX V4.0B  (Rev. 564); Mon Jan 20 14:20:53 MET 1997
 TCP/IP"
        123             SNMP sysLocation                "INSO-3"
        124             SNMP sysContact                 "Valdameri Roberto"
        125             SNMP sysObjectID                "1.3.6.1.4.1.36.2.15.2.3"
        129             isMLM                           FALSE
        130             isSYSMON                        FALSE
        131             isSIA                           FALSE
        132             isManager                       FALSE
        134             isSLM                           FALSE
        135             isSIAOS2                        FALSE
        145             TopM Interface Count            1
        151             TopM Interface List             "172.22.171.212 Up      
  172.22.171.212  <
Unknown>       0xAA0004005024  other               "
        154             IP Status                       Normal(2)
        157             isIPRouter                      FALSE
        179             XXMAP Protocol List             "IP"
        519             IP Name                        
"nepoly.tecno.snam.eni.it"
        536             default IP Symbol List          8
/>


/> snmpwalk nepoly.tecno.snam.eni.it .1.3.6.1.2.1.4.20.1.
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.127.0.0.1 : IpAddress:   127.0.0.1
ip.ipAddrTable.ipAddrEntry.ipAdEntAddr.172.22.171.212 : IpAddress:     
172.22.171.212
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.127.0.0.1 : INTEGER: 3
ip.ipAddrTable.ipAddrEntry.ipAdEntIfIndex.172.22.171.212 : INTEGER: 1
ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.127.0.0.1 : IpAddress:        255.0.0.0
ip.ipAddrTable.ipAddrEntry.ipAdEntNetMask.172.22.171.212 : IpAddress:  
255.255.252.0
ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.127.0.0.1 : INTEGER: 1
ip.ipAddrTable.ipAddrEntry.ipAdEntBcastAddr.172.22.171.212 : INTEGER: 1
ip.ipAddrTable.ipAddrEntry.ipAdEntReasmMaxSize.127.0.0.1 : INTEGER: 65535
ip.ipAddrTable.ipAddrEntry.ipAdEntReasmMaxSize.172.22.171.212 : INTEGER: 65535
/>



/> nmdemandpoll nepoly.tecno.snam.eni.it

11:37:34 ***** Starting demand poll of node nepoly.tecno.snam.eni.it *****
11:37:34   Interface 172.22.171.212 (currently up)
11:37:34     responded to ping
11:37:34   Current polling parameters
11:37:34     scheduled configuration check at 04/17/97 10:39:06
11:37:34     scheduled new node poll at 04/16/97 11:39:06
11:37:34       auto-adjusted polling interval is 900 seconds
11:37:34   Get system identifier
11:37:34   Get system description
11:37:34   Get IP forwarding status
11:37:34   Get IP address table
11:37:34   Get number of interfaces
11:37:34   Get interfaces table
11:37:34     interface sl does not have an IP address
11:37:34     interface ppp does not have an IP address
11:37:34   Get ARP table for discovering secondary interfaces
11:37:34     SNMP response error:  expect ASN type 64, received ASN type 4
11:37:34   Get default routing entry
11:37:35   Get system location
11:37:35   Get system contact
11:37:35   Get ARP table
11:37:35     SNMP response error:  expect ASN type 64, received ASN type 4
11:37:35   Get Middle Level Manager
11:37:35   Get System Information Agent
11:37:35     SNMP error: no such name
11:37:35   Read Node Discovery Table
11:37:35     SNMP error: no such name
11:37:35   Get Manager Product Name
11:37:35     SNMP error: no such name
11:37:35   Verify node name
11:37:35     node name verified to be nepoly.tecno.snam.eni.it
11:37:35 ***** End of demand poll for node nepoly.tecno.snam.eni.it
/>
2232.6PLACEK::DANIELEWSKIWed Apr 16 1997 11:1917
    I have also noticed (using NetView and IRIS) bad BER encoding 
    of ARP cache response of eSNMP agent (Digital UNIX 3.2d-4.0b).
    I had some problems with discovery process when variable
    subnetting was used or there were misconfigured address masks.
    For example, node (1.1.1.1;255.255.255.0) was put in a subnet
    (1.1.1.0;255.255.255.0) or in a subnet (1.0.0.0;255.0.0.0)
    depending on the current state of ARP caches, response time, 
    NetView version, etc. I also had instances, when node 
    (1.2.3.4;255.255.255.0) was put in the network (1.1.1.0;255.255.255.0). 
    Usually it could be cured by letting the autodiscovery finish its first 
    round, add manually networks not discovered, delete all discovered 
    networks, stop and restart all demons. 
      
    Wlodek
    NSIS, Warsaw
     
                                                                  
2232.7try arp tablesMOLAR::SIEGELMS: ZKO1-3/H18 DTN: 381-0035Wed Apr 16 1997 13:2213
    
    Netmon polls the arp tables of a node it may find---which can
    be checked with:
    
        snmpget -c public nodename at.atTable
    
    Polling the arp table in the original message is giving the
    error.
    
    Joanna
    
    
    
2232.8logsZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyWed Apr 16 1997 14:0857
	Thanks Wlodek,

	but to create manually the subnet not discovered by PNV autotopology
	doesn't solve the problem.
	PNV creates again the unnamed subnet and populate it with the nodes
	belonging to the subnet of the PNV server plus a random
	collection of nodes.

	Thanks Joanna,

	Here is the output of the command you suggested.
	In order to save time I reduced the PNV server visibility only
	to itself and the firewall.
	The snmpwalk and snmpget commands and the xnmbrowser never
	get an error! Only autodiscovery and nmmdemandpoll do.
	This is very strange.


/> snmpwalk nepoly.tecno.snam.eni.it at.atTable
at.atTable.atEntry.atIfIndex.1.1.172.22.171.180 : INTEGER: 1
at.atTable.atEntry.atIfIndex.1.1.172.22.171.233 : INTEGER: 1
at.atTable.atEntry.atIfIndex.1.1.172.22.171.240 : INTEGER: 1
at.atTable.atEntry.atIfIndex.1.1.172.22.171.253 : INTEGER: 1
at.atTable.atEntry.atPhysAddress.1.1.172.22.171.180 : OCTET STRING-   (hex):
length = 6
     0:  00 00 f8 30 c5 f4 -- -- -- -- -- -- -- -- -- --     ...0............

at.atTable.atEntry.atPhysAddress.1.1.172.22.171.233 : OCTET STRING-   (hex):
length = 6
     0:  08 00 2b 91 e3 94 -- -- -- -- -- -- -- -- -- --     ..+.............

at.atTable.atEntry.atPhysAddress.1.1.172.22.171.240 : OCTET STRING-   (hex):
length = 6
     0:  00 a0 24 54 23 d3 -- -- -- -- -- -- -- -- -- --     ..$T#...........

at.atTable.atEntry.atPhysAddress.1.1.172.22.171.253 : OCTET STRING-   (hex):
length = 6
     0:  aa 00 04 00 53 24 -- -- -- -- -- -- -- -- -- --     ....S$..........

at.atTable.atEntry.atNetAddress.1.1.172.22.171.180 : OCTET ST
RING-   (hex): length = 5
     0:  01 ac 16 ab b4 -- -- -- -- -- -- -- -- -- -- --     ................

at.atTable.atEntry.atNetAddress.1.1.172.22.171.233 : OCTET STRING-   (hex):
length = 5
     0:  01 ac 16 ab e9 -- -- -- -- -- -- -- -- -- -- --     ................

at.atTable.atEntry.atNetAddress.1.1.172.22.171.240 : OCTET STRING-   (hex):
length = 5
     0:  01 ac 16 ab f0 -- -- -- -- -- -- -- -- -- -- --     ................

at.atTable.atEntry.atNetAddress.1.1.172.22.171.253 : OCTET STRING-   (hex):
length = 5
     0:  01 ac 16 ab fd -- -- -- -- -- -- -- -- -- -- --     ................

/>
2232.9SMURF::DANIELEWed Apr 16 1997 15:0126
Thanks for that last log, it confirms what I just
was looking at.  The Digital UNIX agent has a bug, in that
atNetAddress is of type IP address, not octet string.
(It also returns incorrect data.)

If someone can enter an IPMT I'll get it fixed, and make sure
it's correct in the next release.

There is another, somewhat larger problem, this one w/ NetView (I think).
RFC1213 deprecated the atTable in favor of ipNetToMediaTable.
This means agents may not implement atTable at all, and still
be compliant w/ the RFC.

RFC1213 was issued over 6 years ago.  We may very well choose
not to implement these objects in a future release.

Note also that MIB-II (RFC1213) was later broken up into
component MIBs, one for ip, one for udp, etc.  I do not believe
atTable exists in any of these MIBs.

So it seems clear to me that NetView can't expect to base autodiscovery
on reading the atTable for very long.

Can anyone address this issue?

Mike
2232.10ZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyThu Apr 17 1997 05:1814
	Mike,

	thanks for the cooperation. I'll enter the IPMT this morning.

	What can I do in the meantime with the customer in order to
	implement a workaround with PNV?

	Could you provide a patch of snmpd+os_mibs?

	Thanks a lot, again.


	Gian Alfredo
2232.11SMURF::DANIELEThu Apr 17 1997 09:485
Yes, a patch will be created when you enter the case.
Can you please send me mail or post the case # here?

Thanks,
Mike
2232.12IPMT GOZ100745ZAPATA::DALLAVOG.Alfredo Dall&#039;Avo NSIS-Milan ItalyTue Apr 22 1997 04:4411
	Mike,

	sorry for the delay due to the inertia of the escalation process.

	The IPMT number is GOZ100745.

	Thanks a lot.


	Gian Alfredo