My 2 cents - The most common reason for this problem is some protocol that is disabled on the interface in question being enabled on the other to which the interface connects. For example, OSPF might be disabled on this interface but enabled on the other end to which this interface connects. As a result, the multicast updates reaching this interface would then be discarded as L3 incompletes!
If this counter in incrementing at a reguar interval, it might well be a control packet that is sent out periodically! Regards Lakshmi 2008/6/13 Niels Bakker <[EMAIL PROTECTED]>: > * [EMAIL PROTECTED] (Bit Gossip) [Fri 13 Jun 2008, 14:13 CEST]: > >> we are experiencing a constant presence of "L3 incomplete" on a 1 Gige >> PIC. This is ~1 every 5 mins. Any idea what can be the reason? >> > > You didn't search the archives, did you? > > > The Junos doc says "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." >> This means that L2 is ok so also physical layer is ok? >> > > Ethernet interfaces in Juniper routers work in cut-through mode, therefore > a frame that fails DA check (e.g. an unknown unicast frame flooded by the > switch) is counted again as L3 incomplete. This is a known > limitation/bug/documentation incompleteness. > > > -- Niels. > > -- > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
