Conference 7.286::fddi

    The customer has done some more research and now beleives that the
    Incoming Error Packet rate has to do with unknown protocols (anything
    not IP) and is therefore bogus.
    
    Is this correct?
    
    Thanks, 
    
    Dave

    
    The concentrator calculates the following for Inbound Error Packets:
    
    ifInErrors = sum of ( block check errors + frame alignment errors +
                          frames too long errors + frame status errors )
    
    I believe the unknown protocols the customer is refering to would be
    in ifInUnknownProtos which would be = (unrecognized multicast frame
    destination + unrecognized individual frame destination)
    

    
    
    	These Inbound Error Packets we are seeing must be something else
    than ifInErrors:
    
    
    MCC> show snmp .ip.conc1 interface * all count
    
         Examination of attributes shows:
    			            ifOutErrors = 0
                                  ifOutDiscards = 0
                                ifOutNUcastPkts = 836603     (rising slowly)
                                 ifOutUcastPkts = 1044287    (rising slowly)
                                    ifOutOctets = 163009030  (rising quickly)
                              ifInUnknownProtos = 23925590   (rising moderately)
                                     ifInErrors = 0          (zero!!!!)
                                   ifInDiscards = 188
                                 ifInNUcastPkts = 13316158   (rising slowly)
                                  ifInUcastPkts = 2725953    (rising slowly)
                                     inInOctets = 2570204368 (risingquickly)
                            CounterCreationTime = 4-NOV-1994 17:46:21.19
    
    
    	As you can see, the ifInErrors are zero. The only counter that is
    incrementing at a noticible rate, other than the in and out octets, is
    the Unknown Protocols counter.
    
    	Could this be what MCC is using to compute the Inbound Error
    Packets?
    
    	Thanks,
    
    	Dave

    
    
    	I recently found the following in the DECmcc Performance Analyzer
    Function Module manual:
    
    	Inbound error packets = ifInDiscards+ifInErrors+ifInUnknownProtos
    
    	Since we are having few to no InDiscards and InErrors and a very
    high rate of InUnknownProtos, one can conclude that the InUnknownProtos
    are what is affecting the Inbound Error Packet rate.
    
    	The question then becomes - 
    
    	What does the DC500 consider ifInUnknownProtos? What specifically
    does this mean?
    
    	Thanks,
    
    
    	Dave 

    
    I'll give it a shot...
    
    ifInUnknownProtos = UnrecognizedMulticastFrameDestination +
                        UnrecognizedIndividualFrameDestination
     
    One of the UnrecognizedxxxFrameDestinations will increment if the 
    frame was good and either ( the FC was unrecognized  -or- it was 
    a MAC or SMT frame that was not 48bit addressed -or- a SMT frame
    with the A-bit was set (address recognized) and not a broadcast 
    address or not directly addressed to this station  -or- a LLC 
    broadcast frame but not ARP or BOOTP )
    
    

    
    
    	Wayne,
    
    	Thank you for the preceeding information. This is the kind of stuff
    the customer is interested in. The customer has pointed out another
    issue. These DC500s share rings with GIGAswitches. The
    ifInUnknownProtos on the DC500 increment at a wild rate while the
    inInUnknownProtos on the cooresponding GIGAswitch port increment
    perhaps once every two minutes.
    
    	Therefore the customer says that either the GIGAswitchs or the
    DC500s are calculating inInUnknownProtos incorrectly. How would one
    respond to that apparent truth?
    
    	Thanks,
    
    	Dave

    
        First of all, ifUnknownProtos is not really an error.  All it means
    is that on the station which received the frame, the station didn't
    support the protocol for that frame.  This happens in a variety of
    non-error conditions - take Novell broadcast frames, for example. 
    Novell sends frames to the broadcast address, which forces each station
    to look at the frame.  Concentrators and the GIGAswitch/FDDI system
    don't do any Novell protocol support, so it would get counted as a
    ifUnknownProtocol.
    
        There are a couple of reasons that a concentrator and a
    GIGAswitch/FDDI system sharing a FDDI ring would count ifUnknownProtos
    differently.  Unicast frames directed at either system would not be
    counted on the other system.  Concentrators and GIGAswitch/FDDI
    systems don't necessarily support the same protocols.  If the
    concentrator or the GIGAswitch/FDDI system were originating the frames
    which caused the ifUnknownProtos, it would not be counting them.
    
        Tracking down each and every unknown protocol frame is generally a
    waste of time.  If you *must* do it, I'd start by capturing all the
    broadcast, all the unicast frames directed at the concentrator MAC
    address, and all the unicast frames directed at the GIGAswitch/FDDI MAC
    address.  Sort them by protocol.  Toss out the protocols which aren't
    supported.  Count the rest.  
    
        If this number doesn't match ifUnknownProtos, then you'll have to
    add in the multicast addresses which each device enables and repeat the
    exercise.