[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

1060.0. "How to get default access as ethernet on db620s" by SUBWAY::AMMU () Mon Aug 16 1993 10:39

	how to get default access as ether on b620s        

decbridge 620 - access

decmcc 1.3
ultrix 4.3

No fddi -ring inplace, only loopbacks on fddi ports

mcc> show bridge 08-00-2b-76-0d-e8 line * all char
		 (fddi port addr)

	takes forever to give response back


mcc> show bridge 08-00-2b-76-0d-e9 line * all char
		 (ethernet port addr)
	comesback immediately

on the SNIFFER mcc sendsout rbms request, and response comes back in both
cases, no difference except the time.

All bridges have fddi loopback connectors, and only ethernet side is being 
used. 

when I register the bridge in mcc with ethernet address , it comesback
1st time immediately, then it populates namespace with all 4 mac addresses,
and uses the 1st one, which happens to be fddi port. 

Is there anyway to ask the bridge to use the ethernet port instead of fddi
port when it hits the bridge. 

I even disabled the fddi dipswitch for management off, but no good. 

any ideas. 

thanks

cross posted in mcc and bridge conferences

subway::ammu


T.RTitleUserPersonal
Name
DateLines
1060.1Port 1 broken state may be problemQUIVER::WALTERFri Aug 20 1993 17:4717
    I think I can guess what's causing the long delay in the response. If
    you use the standard FDDI loopback connectors on each of the 620's FDDI
    ports, then to the bridge the ring will appear to be broken and port 1
    will be in the broken state. When MCC sends a packet to the port 1 mac
    address, it has to be "received" on that broken port. I don't mean
    received physically, but the bridge software directs it to that logical
    port since that's the true destination address. I suspect that the
    broken state contributes to the long delay.
    
    To solve the problem, remove the loopback connectors and install a
    fiber patch cord between the two FDDI ports. That will create a legal 
    ring, having one member, the bridge. 
    
    Hope this helps.
    
    Dave