[j-nsp] L3 incompletes

[bbird at epik.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

#-----Original Message-----
#From: Christopher Morrow [mailto:morrowc at ops-netman.net] 
#Sent: Sunday, December 07, 2003 10:39 PM
#To: jeff at groth.com
#Cc: 'Phil Rosenthal'; juniper-nsp at puck.nether.net
#Subject: Re: [j-nsp] L3 incompletes
#
#
#On Dec 8, 2003, at 2:26 AM, Jeff Groth wrote:
#
#> That was my understanding as well.  CDP packets.
#>
#> Jeff
#> (currently on Juniper withdrawal)
#>
#>
#
#Could you not log based on packet size SMALLER than the limit that 
#would equal the 'incompletes' size and see what got logged?

One of our health reports recently indicated a small number of input
errors ( < 1 /sec.), on a Juniper gigE interface.  This is derived
via SNMP ifInErrors counter.  I did verify that L3 incompletes are,
by design, meant to be included in this counter (a knob would be
nice).  I also verified that the L3 incompletes are the cause of the
SNMP reported errors.  The interesting part is that the device this
GigE is connected to is a Foundry, which has FDP/CDP disabled.  It is
also worth mentioning that spanning-tree is disabled on this
interface.  So these are not BPDU's 
CDP should not be counted as a L3 incomplete, and Juniper's web page
concurs.  Juniper's web site reads that CDP will be counted as
'Policed Discards', not 'L3 incompletes'.  Based on my interpretation
of Juniper's definitions of their counters, 'Policed Discards' and
'L3 incompletes' are mutually exclusive.  Although there is some
ambiguity in the wording.

According to Juniper; L3 incompletes are defined as "The number of
packets discarded due to the packets failing Layer 3 header checks.
This counter increments when the incoming packet fails Layer 3
(usually IPv4) checks of the header. For example, a frame with less
than 20 bytes of available IP header would be discarded and this
counter would increment."

Also according to Juniper; Policed discards are defined as "The
frames that the incoming packet match code discarded. The frames were
discarded because they were not recognized or of interest. Usually,
this field reports protocols that the JUNOS software does not handle,
such as the Cisco Discovery Protocol (CDP)." 

CDP doesn't have a L3 header, so I don't believe that Juniper would
consider this Ethernet frame to contain a bad L3 header.  Ethernet
encapsulated CDP packets have a proprietary protocol ID of 0x2000
(some think of this as the Ether type, but that is technically
inaccurate in the case of CDP).  CDP packets are LLC SNAP packets
with an IEEE OUI id of 0x00000c, registered to Cisco.  0x2000 isn't
the Ether type, but a Cisco proprietary protocol ID.  Ether type's
are only defined in the version II frame format, and must be greater
than 0xO5DC

Here is my dilemma.  Since a L3 incomplete is a failed layer 3 header
check, the entire packet size of a L3 incomplete is not
deterministic.  Therefore filter and log wouldn't appear to help
identify what is incrementing this counter.  If Juniper's "packet
match code" is able to identify "frame of interest", based on the
Ether type (and discard accordingly), then the router is actually
detecting a bad packet.  In my case, this interface (and its units)
is configured with inet, iso and mpls.  This interface is also
configured for 802.1q tagging, so the only Ether type frames that the
"packet match code" should not discard as a "policed discard", would
be 0x8100 (.1q), 0x8000 (IPv4), 0x8847 (MPLS uni.), 0x8848 (MPLS
multi), and 0x0806 (ARP).  The only way that I can see getting
visibility to this, is a passive monitoring device.

Any ideas Juniper?  Could this be something that is misinterpreted by
Juniper's "packet match code", but coincidentally has the correct
bits at the correct offset, to look like a L3 packet which the router
is configured for?


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBP9S9AdFQh6ARB7TZEQIbOwCdECMv0uQkCl1woGPha+5uNtSo7rIAn0zR
BLJvJ2DyZWyMq1Fxu+L3ziF7
=sZSi
-----END PGP SIGNATURE-----