Conference netcad::hub_mgnt

1224.0. "DECBridge 900MX issues & questions" by AKRON1::SMITH (Sic Semper Potatum Reclinus) Wed Jul 13 1994 15:02

        
        This memo documents two issues that I have encountered on 
        customer sites with DECbridge 900MX bridges installed.
        
        
        Issue 1:
	(An "offshoot" of note 1098)        
        
        A Cabletron FDDI/Ethernet bridge connects a coax ethernet 
        backbone with three DELNIs.  VAXs connect to the DELNIs.  
        FDDI connects this room with another room with VAXs 
        connected via TP ethernet and eventually to another 
        Cabletron FDDI/Ethernet bridge.
        
        The customer purchased DECbridge 900MXs to replace the 
        Cabletron boxes.  The 900MX in the room with the DELNIs 
        is installed in a Onehub and each AUI port on the 900MX 
        connects to a different DELNI creating three separate 
        bridged LAN segments bridged to FDDI.  In the other room 
        the another 900MX (in a Onehub) connects to VAXs via TP 
        ethernet and to FDDI.
        
        After the upgrade, network backup performance dropped to 
        about 1/10 the normal performance.  The backups used a 
        DECnet transport and data was being backed up from a 
        system in one room to a system with tape drives in the 
        other room.  After much analysis, I had the customer 
        install loopback connector on the DELNI and flip the 
        switch to global where the source system was connected, 
        thereby disabling collision presence test ("heartbeat") 
        while the backup was still running.  The network 
        performance then network performance as viewed from the 
        counters on the source system and on a NG Sniffer 
        immediately jumped to normal.
        
        Question:
        
        Is this an issue with the DELNI/900MX configuration or 
        should heartbeat be disabled on all transceivers 
        connected to the 900MX AUI ports?
        
        
        Issue 2:
        
        On a customer site where 900MX bridges in Onehubs connect 
        ethernet segments to an FDDI ring.  A Novell server is in 
        one room and the client is in another room separated by 
        FDDI and the and the 900MXs.  A certain Intel PC using a 
        native Netware driver functions fine using the server.  
        The same PC using an NDIS driver fails at a certain point 
        while connecting to the server.  As viewed from analyzers 
        on both ethernet segments involved,  the failure is being 
        caused by raw IPX frames not being forwarded by the 900MX 
        on the client side.  In looking at traces from both 
        sides, there are exchanges of messages from the client to 
        the server but at the same (reproducible) point, no 
        further frames are forwarded from the client side (at 
        least not what was expected).
        
        Questions:
        
        Would this observation be a symptom of 900MX bridges not 
        set to forward raw IPX to FDDI (i.e. forwarding "some of the
    	time")?
        
        To setup raw IPX forwarding, after clicking on the box in 
        Hubwatch, is it necessary to power cycle to 900MX for 
        that to take effect?
        
        

    

    
    
    The 900MX bridges always forward raw IPX frames, the management switch
    controls the translated format of the frames on FDDI. So here are the
    two cases:
    
    Raw IPX Switch disabled:
    
    Ethernet frame =      DA : SA : Len : FF FF .....
    FDDI frame     = FC : DA : SA : FF FF .....
    
    Raw IPX Switch enabled:
    
    Ethernet frame =      DA : SA : Len : FF FF .....
    FDDI frame     = FC : DA : SA : AA AA 03 00 00 00 81 37 FF FF ....
    
    So when the switch is enabled, the raw IPX frame is translated as a
    SNAP encapsulated frame with a protocol type of 81-37 (IPX prot type).
    There should not be a condition where the raw IPX frames are forwarded
    sometime and not forwarded other times. The only case under which a
    frame should not be forwarded is if it has errors.When you enabled the
    switch by clicking on the box in HUBwatch, did you click on the Apply
    button on the bottom(just checking all possibilities), because only then 
    the actual set happens in the bridge. Another question, did you enable the 
    switches on both the bridges ? If you enable it only on one bridge, when 
    the translated packet arrives at the far end, it would be translated into 
    a Ethernet V2.0 frame format instead of the desired raw IPX format.
    
    This feature was tested in the lab yesterday evening, using LAN
    Analyzers and it was working fine. If you can provide me with the
    different frame formats you are seeing at either end, I may be able to
    help you out better. Could you also let me know what version of the
    bridge firmware you are running.
    
    By the way the raw IPX feature was first designed and implemented by me
    on the DECbridge 5XX/6XX a couple of years ago ! This feature is quite
    powerful and could be easily misused which could result in problems.
    
    I do not have any response to your Issue 1. I will look into it and
    respond later.
    
    Hope this helps,
    Krishna

    
    
    
    
    RE: .1
    
    Hmmmm...
    
    From what you're telling me,  the raw IPX function is either on or off.
    
    
    In my case, the exchange of protocol works for a few messages, then
    stops. (not what I'd expect in this case!)
    
    Also, as stated in my E-mail to you I have ethernet traces available
    and the 900MXs are V1.2.1 code.