Conference azur::mcc

3178.0. "IP autoconfiguration reports sendto failures and then "hangs" around in LEF" by ASD::MCCROSSAN () Fri Jun 12 1992 10:05

DECmcc T1.2.7
VMS V5.4-3

It seems that when the .cf file is configured to permit 132.157.0.0 255.255.0.0
to allow the portals (IP-over-DECnet router) the following errors are reported,
the data collection seems to proceed to a point and then the process sits
out there forever in LEF state. Doing a ^C once causes the RT scan canceled
message, doing it again says its canceled all scan but still nothing happens.
Only a ^Y aborts.

the config file I used was the standard one created by autoconfig and the 
gwy is 16.32.48.100.



Aborted   router 132.157.234.79 (Ptl.58.591) **sendto() failure [invalid argumen
t]**  queues=[0,36,12,92] = 140
Querying router 132.157.237.163 (Ptl.59.419) via 16.52.16.254
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.237.
163 (Ptl.59.419) failed - sendto() failure [invalid argument]
Aborted   router 132.157.237.163 (Ptl.59.419) **sendto() failure [invalid argume
nt]**  queues=[0,36,12,93] = 141
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.237.
163 (Ptl.59.419) failed - sendto() failure [invalid argument]
Aborted   router 132.157.237.163 (Ptl.59.419) **sendto() failure [invalid argume
nt]**  queues=[0,36,12,93] = 141
Querying router 132.157.90.7 (Ptl.22.519) via 16.52.16.254
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.90.7
 (Ptl.22.519) failed - sendto() failure [invalid argument]
Aborted   router 132.157.90.7 (Ptl.22.519) **sendto() failure [invalid argument]
**  queues=[0,36,12,94] = 142
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.90.7
 (Ptl.22.519) failed - sendto() failure [invalid argument]
Aborted   router 132.157.90.7 (Ptl.22.519) **sendto() failure [invalid argument]
**  queues=[0,36,12,94] = 142
Querying router 132.157.90.144 (Ptl.22.656) via 16.52.16.254
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.90.1
44 (Ptl.22.656) failed - sendto() failure [invalid argument]
Aborted   router 132.157.90.144 (Ptl.22.656) **sendto() failure [invalid argumen
t]**  queues=[0,36,12,95] = 143
$3$dua0:[sys3.syscommon.][syslib]mcc_ac_ip.exe;1/add_sys: query for 132.157.90.1
44 (Ptl.22.656) failed - sendto() failure [invalid argument]
Aborted   router 132.157.90.144 (Ptl.22.656) **sendto() failure [invalid argumen
t]**  queues=[0,36,12,95] = 143
Finished  router 16.52.16.1 (acton_w.bb.dec.com)  queues=[0,35,12,96] = 143
Finished  router 16.11.48.6 (grand-coulee.crl.dec.com)  queues=[0,34,12,97] = 14
3
Finished  router 16.52.32.4 (crl-ct-1.bb.dec.com)  queues=[0,33,13,97] = 143
Finished  router 16.1.224.18 (fubar.pa.dec.com)  queues=[0,32,14,97] = 143
Finished  router 16.1.240.35 (pa-easy.pa.dec.com)  queues=[0,31,14,98] = 143

I have entered this note as QAR 3166

	The default config file has following parameters:

	1. gwy  16.20.0.173
	2. permit 16.0.0.0   255.0.0.0
	3. permit 132.157.0.0 255.255.0.0
	4. host-permit 16.20.0.0   255.255.255.0
	5. host-deny 0.0.0.0 0.0.0.0
	6. community public 0.0.0.0 0.0.0.0
	7. options -r 2 10
	
	Of these if you leave 2. above untouched, you are basically 
	telling IP to go find the entire DECNET IP network.

	Some one in my group has been able to do just that but it
	took about 2 days. And this was done on Ultrix.

	When you type ^C, the IP program tries to cancel all its request
	It does take a long time to do a proper cleanup operation.
 	
	Can you run the same software with a mask that limits the 
 	scope to say 16.32.0.0.0?

	Let us know if this too hangs your system.

	- Anil Navkal

	

	Limiting the search to something like 16.32.0.0 doesn't get the objects
	that are causing the problems which are the PtlNets. 

	I can run this successfully without the permit 132.157.0.0 255.255.0.0
	to get a picture of the routers and the sub-nets using 16.0.0.0. Its
	only when I search 16.0.0.0 and keep the 132.157.0.0 permit around
	that the sendto error is reported on the PtlNets. 

	Also, I only eventually used ^C to abort. If I hadn't, the process
	would have hung around for what seems like forever as I had left it 
	over a weekend without any processing.

	Is there any more information I can give you to help with this?

	Regards,

	Linda

The answer to QAR 03166 has arrived.
-=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-

        Ulla is working on the QAR. When we asked arround for what
        you want to do, we were told that specifying a portal as gateway may
        do  the trick. In that case you don't have to give the permit command
        for 16.*.*.*. When we tried this at our end we got all the
        portals on one map. I a wondering if this is all you want to find
        out. If the answer is yes then perhaps we can close this qar,
        indicating the above workarround.

        - Anil Navkal

-=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-=--=-


BTW, if someone in your group has a QAR account, you can probably follow
up on this yourself rather than waiting for a transfer from notes.

-- Erik