Discards - vEdge Interface

[bradleyordner]

Hi, 

I see a lot of inbound discards on my ISP interfaces attached to my vEdge 5ks. Is there any commands I can use to narrow it down? There is a command - show interfaces errors, but is the error the actual discard?

Brad 

[ekhabaro]

yes, most of the times, see this example from the TAC lab:

vEdge1# show interface statistics ge0/0

                                                                                                                   PPPOE  PPPOE  DOT1X  DOT1X
                AF    RX                  RX      RX      TX                  TX      TX     RX   RX    TX   TX    TX     RX     TX     RX
VPN  INTERFACE  TYPE  PACKETS  RX OCTETS  ERRORS  DROPS   PACKETS  TX OCTETS  ERRORS  DROPS  PPS  Kbps  PPS  Kbps  PKTS   PKTS   PKTS   PKTS
-----------------------------------------------------------------------------------------------------------------------------------------------
0    ge0/0      ipv4  3765674  651559865  0       404487  3228700  594411312  0       2      16   21    13   17    -      -      0      0

vEdge1# show interface errors ge0/0
interface vpn 0 interface ge0/0 af-type ipv4
 arp-add-fails           72991
 rx-arp-reply-drops      0
 rx-arp-rate-limit-drops 0
 tx-arp-rate-limit-drops 1
 rx-arp-non-local-drops  399704
 tx-arp-request-fail     0
 tx-no-arp-drops         1
 rx-ip-ttl-expired       0
 interface-disabled      0
 rx-policer-drops        0
 rx-non-ip-drops         0
 filter-drops            0
 mirror-drops            0
 cpu-policer-drops       4791
 tx-icmp-policer-drops   0
 tx-icmp-mirrored-drops  0
 split-horizon-drops     0
 route-lookup-fail       0
 bad-label               0
 rx-policer-remark       0
vEdge1#

If you sum up cpu-policer-drops and rx-arp-non-local-drops drops, you will get RX drops from the interface statistics. 

[bradleyordner]

Thanks, I have a similar output. Is it normal to discard so much non local
ARP? This isn’t considered broadcasts is it?

I have my next hop constantly arping for my address although i see it in
tcp dump so it isn’t discarded I believe.

Is there any debugs to capture discards?

[ekhabaro]

yes it's normal. 

rx-arp-non-local-drop — Received ARP packets that do not match the destination IP address of any local IP address.

https://www.cisco.com/c/en/us/td/docs/routers/sdwan/command/sdwan-cr-book/operational-cmd.html#wp3001399095 

These packets may be counted under broadcast counter as well most likely, but not sure.

> Is there any debugs to capture discards?

tcpdump ?

[bradleyordner]

I tired this, but found discrepancy.

RX Drops - 57 

NON Local - 45

No policer yet. 

Ill keep my eye on it. As long as it does not impact any performance? 

[pgasparovic]

Sometimes just double-check if switch and VPN0 trunk a and service VPN subint configurations match as was my today case greatly overlooking that due to some forgotten experiments the switch was in access and vEdge in trunk, so ARPs were plain dropped.

[mansi-gupta]

I have a serious issue getting drops on Nmobile VPN3 interface o vEdge 1100-6G , my customer is only concerned about these errors and basis upon this customer keeping bad eyes on us. He is not letting us know how it is service impacting , but he is pushing us to see ourself on router and NMS tools Solarwinds the dicards errors everytime.
We already advised him taht this is non-service impacing as per cisco TAC guidelines, but still no compromise from his side .

I reallly dont want these errors on interface , anyone/anywhere/TAC/ can provide a resolution anyhow ?

interface vpn 3 interface ge0/3.350 af-type ipv4

arp-add-fails 95310

rx-arp-reply-drops 0

rx-arp-rate-limit-drops 0

tx-arp-rate-limit-drops 59194

rx-arp-non-local-drops 878263

tx-arp-request-fail 0

tx-no-arp-drops 161

rx-ip-ttl-expired 24038

rx-ip-errors 0

interface-disabled 0

rx-policer-drops 0

rx-non-ip-drops 0

filter-drops 0

mirror-drops 0

cpu-policer-drops 81847

tx-icmp-policer-drops 3

tx-icmp-mirrored-drops 0

split-horizon-drops 1

route-lookup-fail 0

bad-label 0

tx-interface-disabled 0

rx-dmac-filter-drops 0

rx-wred-drops 0

rx-interface-not-found 0

rx-inb-errors 0

rx-oversize-errors 0

rx-fcs-align-errors 0

rx-undersize-errors 0

tx-underflow-pkts 0

tx-collision-drops 0

rx-policer-remark 0

tx-arp-reply-rate-limit-drops 91011

[mansi-gupta]

Dear All,

Through collaboration within our TDA community, we were able to identify a solution by implementing an implicit ACL on the SD-WAN device. This implicit ACL enabled us to precisely determine the sources of packet drops, including rx_arp_non_local_drops and filter_drops. Additionally, we observed rx_implicit_acl_drop counts, which are categorized as NAT drops. Due to the DIA interface present on both SD-WAN sides, and through the TLOC extension, LAN packets are re-NATed (for example, on the secondary DIA via the TLOC interface). We noticed that the number of BFD sessions on the primary device was significantly lower compared to the secondary device. The port-hopping between both interfaces made a notable difference; consequently, discards on the interface have been drastically reduced. This outcome is highly satisfactory, and the discard issue on the WAN interface is now resolved. Cisco still needs to investigate how port-hopping functioned and why NAT drops were occurring.

Best regards.

show log tmplog/vdebug
show system statistics | in drop
--More-- rx_drops : 0
rx_urpf_drops : 0
ip_v6_mcast_drops : 0
ip_fwd_mcast_life_exceeded_drops : 0
rx_mcast_policy_fwd_drops : 0
rx_mcast_mirror_fwd_drops : 0
ip_fwd_to_cpu_nat_drops : 0
nat_xlate_outbound_drops : 54
--More-- rx_gre_drops : 0
rx_gre_policer_drops : 0
rx_implicit_acl_drops : 363848
rx_ip6_ipsec_drops : 0
rx_sa_ipsec_drops : 0
rx_spi_ipsec_drops : 105
rx_replay_drops : 4
rx_replay_integrity_drops : 2
rx_next_hdr_ipsec_drops : 0
rx_mac_compare_ipsec_drops : 0
rx_err_pad_ipsec_drops : 0
rx_ipsec_policer_drops : 0