Conference 7.286::fddi

    on the bridge which you can't ping... Is the IP address mapped to
    the Port 1 (FDDI) address?  (normally it should be) Does the ping
    message originate from a station on the ethernet or FDDI ??
    When you manage the bridge using DECMCC do you use the address 
    on Port 1 or Port 2?  (you can use either one).
    
    ken

    Hi ken
    Yes the Ip address is mapped to port 1
    the ping is from the FDDI side
    MCC is using the port 1 address
    
    Regards Richard
    

    well, it should work... I'm not sure how deep you have gone into this
    so I will ask a few more questions.  you verified the backup bridge
    has an ip address?  (dumb question I know, but I've seen it happen).
    IF it responds to the MCC request then it can recognize it's own
    address and should also respond to the ping request.  Is it possible
    for you to check to see if the ping request gets onto the FDDI ring?
    
    ken

    Ken
    if i make the FDDi port go forwarding by removing the enet connection
    the bridge will respond to PING requests
    when I plug the enet back in the bridge will still respond BUT
    only while the ip/enet address is in the router 
    once the arp cache has timed out  (cisco ags+) the bridge agin doen't
    respond to the ping.
    If i clear the arp cache on the router      the bridge agin will not
    respond to pings
    
    ta rijo

    >if i make the FDDi port go forwarding by removing the enet connection
    >the bridge will respond to PING requests
    
    In the first note .0 you said the FDDI port was in forwarding,
    but here in note .4 it seems that maybe the FDDI port was in
    backup mode (since you said you "make" it go into forwarding
    implying it was in backup mode before).
    
    When the bridge does not respond to the ping, is the FDDI link
    in a backup state?  When the bridge is in a backup state one
    of the 2 links is still active and the other is in backup.
    
    It seems like maybe the bridge is not responding when the FDDI
    link enters the backup state?  Does this make sense?
    
    ken

    KEN
    My fault I ment that by removing the enet connection the bridge was now
    ping able as it was now not inbackup for the other bridge.
    i am unable to ping the bridge if either port is in backup 
    IF this bridge is one of a pair
    BRIDGE 'A' manageable MCC and PING
    BRIDGE 'B' manageable MCC but not PINGABLE if either port is in backup
    
    I can't Ping bridge 'B' if i am connected to the FDDi or Enet side
    
    hope this helps
    richard
    
    ____________________FDDI RING____________________________________________
    	|					|
    	|fordwarding				|Fordwarding
      'A' bridge				'B' bridge
    	|					|
    	|forwarding				|backup
    	|					|
    __________________ENET BACKBONE__________________________
	
    
    

	Reading your "answers to more questions", I thinh the host you ping from and the bridge are in
	different networks.Also, router is on the ethernet side of the LAN.My guess is that Arp Broadcast
	is not going acrross the forwarding link. This can be confirmed if you can make a manual entry
	in the ARP cache on the host you ping from.
		If you have access to a UNIX box, then try traceroute command to see how far it goes. I think
	it will stop at the router.


	Naeem.

               <<< UPSAR::USER$411:[NOTES$LIBRARY]FDDI.NOTE;1 >>>
                        -< FDDI - The Next Generation >-
================================================================================
Note 2009.7                    Decbridge510 and IP                        7 of 7
WARFUT::NAEEM                                         9 lines  24-APR-1996 12:27
                              -< Arp Broadcast. >-
--------------------------------------------------------------------------------
Reading your "answers to more questions", I thinh the host you ping from 
and the bridge are in different networks.Also, router is on the ethernet 
side of the LAN.My guess is that Arp Broadcast is not going acrross the 
forwarding link. This can be confirmed if you can make a manual entry
in the ARP cache on the host you ping from.
If you have access to a UNIX box, then try traceroute command to see how 
far it goes. I think it will stop at the router.


Naeem.

    There is now a fix for this problem in the DEC Bridge 500 Series.
    It would not respond to ARP requests when in Backup mode.
    
    the new image is at: NPSS::PUBLIC$DSK:[INTERCHANGE]5XX_V16.SYS
    
    ken