drops for unrecognized upper-level. NP counter LOOP

[Peter L]

Hi

Im seeing drops for unrecognized upper-level protocol on an untagged interface connected to an 1812. Checked the cpe and couldn't find any protocol that is configured in the cpe that is disabled in the ASR9K (CDP, IPV6 ndp).

Did a clear of the counters of the interface and the np to see if i could match what it could be that caused this. Seems like its the NP counter LOOP that is causing the drop counter to increment. Couldn't find any information on what kind of traffic this can be.  Any idea what this could be?

RP/0/RSP0/CPU0:xxxx#show interfaces gigabitEthernet 101/0/0/18
Fri Sep  4 12:13:26.545 CET
GigabitEthernet101/0/0/18 is up, line protocol is up
  Interface state transitions: 1743
  Hardware is GigabitEthernet/IEEE 802.3 interface(s), address is 84b8.027d.fde3 (bia 84b8.027d.fde3)
  Description: To xxxxx;
  Internet address is 78.77.42.98/31
  MTU 9216 bytes, BW 30000 Kbit (Max: 100000 Kbit)
     reliability 255/255, txload 0/255, rxload 0/255
  Encapsulation ARPA,
  Full-duplex, 100Mb/s, link type is force-up
  output flow control is off, input flow control is off
  Carrier delay (up) is 100 msec, Carrier delay (down) is 100 msec
  loopback not set,
  ARP type ARPA, ARP timeout 04:00:00
  Last input 00:00:00, output 00:00:00
  Last clearing of "show interface" counters 01:45:29
  30 second input rate 0 bits/sec, 0 packets/sec
  30 second output rate 0 bits/sec, 0 packets/sec
     4356 packets input, 391166 bytes, 0 total input drops
     633 drops for unrecognized upper-level protocol <---------------------
     Received 0 broadcast packets, 0 multicast packets
              0 runts, 0 giants, 0 throttles, 0 parity
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     3634 packets output, 319351 bytes, 0 total output drops
     Output 0 broadcast packets, 0 multicast packets
     0 output errors, 0 underruns, 0 applique, 0 resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions

RP/0/RSP0/CPU0:xxxxxx#show controllers np counters np1 location 0/0/CPU0
Fri Sep  4 12:13:27.957 CET

                Node: 0/0/CPU0:
----------------------------------------------------------------

Show global stats counters for NP1, revision v2

Read 26 non-zero NP counters:
Offset  Counter                                         FrameValue   Rate (pps)
-------------------------------------------------------------------------------
  16  MDF_TX_LC_CPU                                          47673           8
  17  MDF_TX_WIRE                                            30141           5
  21  MDF_TX_FABRIC                                          29141           5
  25  PARSE_ENET_SAT_RECEIVE_CNT                             36119           6
  33  PARSE_FAB_RECEIVE_CNT                                  17674           3
  37  PARSE_INTR_RECEIVE_CNT                               3270289         516
  41  PARSE_INJ_RECEIVE_CNT                                  12783           2
  49  PARSE_TM_LOOP_RECEIVE_CNT                              30535           5
  67  PRS_HEALTH_MON                                         30535           5
  76  INTR_FRAME_TYPE_7                                      40379           6
 105  PARSE_RSP_INJ_FAB_CNT                                  15096           2
 107  PARSE_RSP_INJ_DIAGS_CNT                                  210           0
 109  PARSE_EGR_INJ_PKT_TYP_IPV4                             15096           2
 120  PARSE_LC_INJ_PORT_CNT                                  12677           2
 121  PARSE_LC_INJ_DIAGS_CNT                                   106           0
 284  DBG_RSV_EP_L_RSV_ING_L3_IFIB                           26223           4
 285  DBG_RSV_EP_L_RSV_ING_L3_IFIB_MATCH                     26223           4
 288  DBG_RSV_EP_L_RSV_ING_L3_RSLTS_MATCH                    26223           4
 289  DBG_RSV_EP_L_RSV_ING_PUNT                              74106          12
 776  ARP                                                      222           0
 782  LOOP                                                     633           0 <--------------
 790  DIAGS                                                    106           0
 902  PUNT_STATISTICS                                        40379           6
 904  PUNT_DIAGS_RSP_ACT                                       105           0
 906  PUNT_DIAGS_RSP_STBY                                      105           0
1004  PUNT_SDP                                                6333           1

/Regards Peter

[mivens · Accepted solution]

I'm guessing it's the LOOP ethertype (0x9000)

Maybe you have keepalive configured on the interface on the 1812?

[Peter L]

Hi Mark

No keepalive on the interface in the 1812 did the trick so you was right Mark. But wouldn't this mean that in case of link failure the interface would still be up in the 1812? Or do i remember how the keepalive function is supposed to work incorrectly.

Maybe better to live with an incremental  "drops for unrecognized upper-level protocol" counter then to disable keepalive in the cpe..

Regards Peter

[xthuijs]

wanted to add that you can see the np descriptions with this command:

RP/0/RSP0/CPU0:A9K-BNG#show controller np descriptions loc 0/0/cpu0 | i LOOP
Sat Sep  5 07:13:12.587 EDT
LOOP                                                      Punt     Punt Ingress ELOOP protocol frames - layer3 interface only

that ether keepalive is very bare and doesnt provide for much keepalive actually in todays networks. you of course have layer one detection at the optical level and if you like to do some higher level service verification then you probably want to be looking at ipsla or bfd.

Eloop is merely a datalink check, so rather useless.

The fact that a9k drops it as higher level proto drop means that we dont do anything with it btw, we haveno handler for it, so they are in fact dropped.

cheers!

xander

[Peter L]

Hi Xander

Nice that you have added a descriptions for NP in the CLI. Makes it a bit easier to find out what going on when you see something strange in your np counters.

Yeah maybe keepalive isn't that useful in today networks. The reason that we got this "problem" was that we moved this site from a port in the 7600 that was error free to an ASR9K . And the people that moved the connection thought that something was wrong because of the unrecognized upper-level drops counter. But im guessing that i need to educated my staff a bit more what can cause unrecognized upper-level drops or disable keepalive  on a lot of cpe's....

Regards Peter

[xthuijs]

hi peter,

I have a write up on the unrecognized proto drops here that may help:

https://supportforums.cisco.com/document/59521/asr9000xr-drops-unrecognized-upper-level-protocol-error

the nasty thing is they count against the interface drops hence also on the ifdrops of the ifmib.

soon we have an enhancement whereby we have drop templates whereby you can define what counts are included or excluded in the interface drop count registration so your mgmt stations dont get overworried seeing an ifdrop.

cheers

xander

[AARON WEINTRAUB]

That would be great, as we get input drops against an input ACL and also I believe against a TTL exceeded, neither of which are particularly important for these purposes... Of course, a per interface breakdown of all the drops without having to query the NP and figure out which port is responsible for which drops would be even better.