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

Conference 7.286::fddi

Title:	FDDI - The Next Generation

Moderator:	NETCAD::STEFANI

Created:	Thu Apr 27 1989
Last Modified:	Thu Jun 05 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	2259
Total number of notes:	8590

316.0. "To PING or NOT to PING" by CSC32::WOESTEMEYER (Why??...Why not!!!) Tue Jul 30 1991 16:38

This morning V3.0.0 was downline loaded in to a DECbridge 500.  This
was done so I could try and test the SNMP managablity using the DECmcc
TCPIP/SNMP access module.

The bridge was given an IP address of 16.63.0.208, the station running
the access module is 16.63.0.27.  I tried to use UCX and loop to the 
bridge address, this failed with a 'does not respond' message.  I then
then tried setting the bridge IP Gateway address to 16.63.0.27, same result. 

Even thought this failed I still tried to register the bridge in MCC, but
this also failed with a 'target does not respond'.  Since the TCPIP/SNMP
access module must be able to get a response of the entity before registration
can be completed, this is also true with all other MCC entities, I wonder
if the new software on the bridge responds to loops/pings?  If not we will
not be able to manage it with our own SNMP products.  

Just to forstall the enevitable question, yes the workstation and the bridge
are on the same segment.  The bridge access module, from MAKO, was used to
set the IP address on the bridge.

To PING or not to PING
Any Ideas?

Steve Woestemeyer
CSC/CS - NSU/LAT

T.R	Title	User	Personal Name	Date	Lines
316.1	The answer is..TO PING the U*IX way	LEVERS::KRISHNA		`Tue Jul 30 1991 20:08`	29
	Hi, The DECbridge 500 firmware version 3.x.x does respond to pings. By pings I mean the standard ICMP Echo request as this is what is used in the ping program running on the U*IX systems. I have not used UCX and am not sure if the loop message you are referring to is the same. The DECbridge 500 has been tested for response to pings using Ultrix systems here in our lab and by our field test sites using other Unix systems. Now trying to diagnose your problem, it would be useful if the following questions are answered : a. Does UCX use the ICMP Echo request to implement the loop/ping messages ? b. Can you verify using MAKO if the IP address of the bridge is what you think it should be ? c. In the process of pinging a device an ARP (Address Resolution Protocol) request is issued to get the ethernet address of the device you are trying to ping. Is it possible in UCX to look at the ARP cache to verify that the DECbridge in fact responded with its hardware address ? Please let me know if you need more help. regards Krishna
316.2	It's ICMP	STKHLM::TORGNY		`Wed Jul 31 1991 06:02`	34
	Hi, According to the help file it is ICMP. Regards, Trogny... $ ucx help loop LOOP The LOOP command tests the connectivity path to a specific host in the network by causing test blocks of data to be transmitted to that host. This test is implemented by ICMP messages passed at the IP level. For this reason, it is not possible to test a particular protocol. If no host_name is specified in the command then loopback testing will occur to the address associated with the local host's name. NOTE: this is not the same as the internet localhost, 127.0.0.1. Format: LOOP [host_name] Additional information available: /ADDRESS /TIMEOUT LOOP Subtopic? Exit $
316.3	One works, One doesn't	CSC32::WOESTEMEYER	Why??...Why not!!!	`Wed Jul 31 1991 10:13`	8
	Looks like I have some more work to do. I have 2 paths to the DECbridge 500 on 2 different segments, one through the ethernet port, the other through the FDDI ring. ELMS and the bridge access module work fine using either path, but PING and the SNMP access module only work if I use the FDDI path. I think I'll look at timeouts first. Thanks for the replies, Steve