Conference 7.286::fddi

>Note 1956.3  
>
>    Here is the exact text of the messages:
>    
>    Dec 24 00:59:27 bo vmunix: fta0: Illegal [Len=4676] packet: DA:
>    08-00-2b-b3-e1-
>    a0 => SA: 00-00-0c-17-a6-f0
>    Dec 24 00:59:27 bo vmunix: fta0: Illegal [Len=4676] packet: DA:
>    08-00-2b-b3-e1-
>    a0 => SA: 00-00-0c-17-a6-f0
>    Dec 24 01:03:43 bo vmunix: fta0: Illegal [Len=6682] packet: DA:
>    08-00-2b-b3-e1-
>    a0 => SA: 00-00-0c-17-a6-f0
>    
>    She also is seeing these:
>    
>    Dec 12 14:54:02 bo vmunix: fta0: Illegal length, packet dropped; len =
>    6968
>    Dec 12 15:24:06 bo vmunix: fta0: Illegal length, packet dropped; len =
>    8000
>    Dec 12 16:04:25 bo vmunix: fta0: Illegal length, packet dropped; len =
>    4643
>    
>    Are they pointing to the same thing??
>    

Sorting and culling ...

Dec 12 16:04:25 bo vmunix: fta0: Illegal len = 4643
Dec 24 00:59:27 bo vmunix: fta0: Illegal [Len= 4676] 
Dec 24 00:59:27 bo vmunix: fta0: Illegal [Len= 4676] 
Dec 24 01:03:43 bo vmunix: fta0: Illegal [Len= 6682] 
Dec 12 14:54:02 bo vmunix: fta0: Illegal len = 6968
Dec 12 15:24:06 bo vmunix: fta0: Illegal len = 8000
    
Don't tell me, let me guess -- They have a Cisco router on their network!?

The pattern here is that SA: 00-00-0c-17-a6-f0 is sending illegal frames
on the network.  (Aren't they clever!)  Our adapters/drivers "properly"
reject them.  I haven't seen this first hand but the pattern is clear.

Our PDQ-based adapters can handle oversize packets up to "around 8100" bytes.
I have personally sent and received 5500 byte packets no problem.  However,
in the event that your big packet sender ever sends packets >8192 bytes
our adapter will crash.  Packet size is contained in a 13-bit field and if
this ever overflows you are in the unknown area of behavior.  Based on the
sizes you posted there is every reason to expect packets >8192 bytes sooner
or later.  I'd love to get my analyzer on a network card with this problem.

What is our party line on FDDI nodes that send oversize packets?  The FDDI
spec on max frame size is explicit.  Your DEFEA/DEFPA has a hardware
limitation based on max frame size being legal.

Chuck

    
    00-00-0c is assigned to cisco so that gives you a place  to start.
    
    Not the first time we've seen this.
    
    Bill
    

    
    Hi Bill,
      I'll let the customer.  Does this imply the cisco has a h/w problem,
    or would it be in the software on it??  What were the other problems
    you've seen?  I'd like to give them as much info as possible.
    
    thanks,
     greg

    Hi,
      I got this back from the customer.  Any comments??
    
    We think we've found the giant problem on the fddi ring harvest is
    connected to.  As suspected the Cisco AGS+ upstream is transmitting 
    malformed packets that lack the terminating or "T" symbol and the 
    E-A-C bits from the end of the frame. 
    The other hosts on that ring seem to ignore these packets, the Cisco
    routers ignore them as witnessed on their "frame ignored counters".
    We suppose that these bad frames confuse the Alpha's fddi card somehow,
    perhaps only reacting incorrectly to the few bad frames that it percieves as
    giants.
    
    It has been recommended that the fddi interface and perhaps the
    applique on the offending router be replaced.  I will advise when 
    this has been accomplished.I still think we need to pursue DEC 
    fixing their end of it.  I think the consensus was that the Alpha is 
    not reacting correctly either.
    

    >>It has been recommended that the fddi interface and perhaps the
    >>applique on the offending router be replaced.  I will advise when 
    >>this has been accomplished.I still think we need to pursue DEC 
    >>fixing their end of it.  I think the consensus was that the Alpha is 
    >>not reacting correctly either.
    
    Hey, if Cisco is sending oversized frames, or if we think they're
    oversized frames because the Cisco isn't terminating them properly then
    too bad.  We're not about to change our adapter architecture to handle
    greater than 8K sized packets when in fact we don't have to handle
    anything biggger than ~4500 bytes.
    
    As for the bad frame handling issue, I'll let one of the FDDI experts
    comment on whether they think we're doing the wrong thing.
    
    /l

	I have been told that the problem is most likely a cisco AGS+ 
linecard firmware bug that appears load related.
Changing the fddi interface or applique had no effect on the problem 
in a case involving one of my customers.

	What eliminated the problem was changing the way the 
line card buffered and routed data via the cisco command:

	NO IP ROUTE-CACHE CBUS

on the cisco AGS+ for the linecards in question. This makes the 
router less efficient but eliminates the oversize frame problem.

Unix Engineering has a patch for 3.2C that bypasses the problem
on a DEFPA by restarting the card after it halts without a 
reboot.

Rich


>================================================================================
>Note 1952.5      illegal packet errors on osf 3.2 console/defpa           5 of 5
>NETCAD::STEFANI "I *CAN* drive 65!"                  16 lines  28-FEB-1996 10:16
>--------------------------------------------------------------------------------
>
>    >>It has been recommended that the fddi interface and perhaps the
>    >>applique on the offending router be replaced.  I will advise when 
>    >>this has been accomplished.I still think we need to pursue DEC 
>    >>fixing their end of it.  I think the consensus was that the Alpha is 
>    >>not reacting correctly either.
>    
>    Hey, if Cisco is sending oversized frames, or if we think they're
>    oversized frames because the Cisco isn't terminating them properly then
>    too bad.  We're not about to change our adapter architecture to handle
>    greater than 8K sized packets when in fact we don't have to handle
>    anything biggger than ~4500 bytes.
>    
>    As for the bad frame handling issue, I'll let one of the FDDI experts
>    comment on whether they think we're doing the wrong thing.
>    
>    /l
>