[c-nsp] IOS-XR and interface discards (input)

[Hank Nussbacher]

At 21:31 14/05/2015 +0200, Mikael Abrahamsson wrote:
>On Thu, 14 May 2015, Hank Nussbacher wrote:
>
>>The config on the interface looks like this:
>>
>>interface TenGigE0/1/1/7
>>mtu 9028
>>ipv4 unreachables disable
>>ipv6 nd dad attempts 5
>>ipv6 address 2001:798:28:20aa::6/126
>>monitor-session No1 ethernet
>>flow-control bidirectional
>>carrier-delay up 100 down 4000
>>load-interval 30
>>flow ipv4 monitor fmp-nfsen sampler fsm-nfsen ingress
>>transport-mode wan
>>ipv4 access-group catch13-ing ingress
>>!
>>
>>Any clue would be helpful for us to begin to debug this issue.
>
>I would look at this:
>
>http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-0/troubleshooting/guide/tr40asr9kbook.pdf 
>, especially the "show controller interface TenGigE0/1/1/7 stats" output.

Thanks.  The stats looks clear:
RP/0/RSP0/CPU0:GP1#show controller  TenGigE0/1/1/7 stats
Thu May 14 22:47:24.492 IDT
Statistics for interface TenGigE0/1/1/7 (cached values):

Ingress:
     Input total bytes           = 64749515187975
     Input good bytes            = 64749515187975

     Input total packets         = 56263865420
     Input 802.1Q frames         = 0
     Input pause frames          = 0
     Input pkts 64 bytes         = 3669376552
     Input pkts 65-127 bytes     = 6922264753
     Input pkts 128-255 bytes    = 1119116057
     Input pkts 256-511 bytes    = 848490198
     Input pkts 512-1023 bytes   = 1106852656
     Input pkts 1024-1518 bytes  = 42597682434
     Input pkts 1519-Max bytes   = 82772

     Input good pkts             = 56263865410
     Input unicast pkts          = 56262343834
     Input multicast pkts        = 1521473
     Input broadcast pkts        = 113

     Input drop overrun          = 0
     Input drop abort            = 0
     Input drop invalid VLAN     = 0
     Input drop invalid DMAC     = 0
     Input drop invalid encap    = 0
     Input drop other            = 0

     Input error giant           = 0
     Input error runt            = 0
     Input error jabbers         = 0
     Input error fragments       = 0
     Input error CRC             = 5
     Input error collisions      = 0
     Input error symbol          = 0
     Input error other           = 5

     Input MIB giant             = 82772
     Input MIB jabber            = 0
     Input MIB CRC               = 5

Egress:
     Output total bytes          = 16487074186716
     Output good bytes           = 16487074186716

     Output total packets        = 34302407278
     Output 802.1Q frames        = 0
     Output pause frames         = 53469
     Output pkts 64 bytes        = 9983012845
     Output pkts 65-127 bytes    = 12091864296
     Output pkts 128-255 bytes   = 994597516
     Output pkts 256-511 bytes   = 839278845
     Output pkts 512-1023 bytes  = 814935894
     Output pkts 1024-1518 bytes = 9578715883
     Output pkts 1519-Max bytes  = 2000

     Output good pkts            = 34302407278
     Output unicast pkts         = 34302336577
     Output multicast pkts       = 68701
     Output broadcast pkts       = 0

     Output drop underrun        = 0
     Output drop abort           = 0
     Output drop other           = 0

     Output error other          = 0

Another issue might be SPAN ports.  We do:

TenGigE0/0/1/2 -> TenGigE0/1/1/4
TenGigE0/1/1/7 -> TenGigE0/1/1/4

Looking at:

http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-2/interfaces/configuration/guide/hc42asr9kbook/hc42span.html#wp1395653

Specifically:

"Performance Impact with Traffic Mirroring

It is recommended that you do not mirror more than 15% of your total
transit traffic. On the Cisco ASR 9000 Ethernet Line Card, that uses Ten
Gigabit Ethernet interfaces or bundle interfaces there is a limit of
1.5G of data on each of the ingress and egress traffic that can be
mirrored. This limitation is not applicable on the Cisco ASR 9000
Enhanced Ethernet Line Card. - See more at:
https://supportforums.cisco.com/document/59721/asr9000xr-troubleshooting-
packet-drops-and-understanding-np-drop-counters#sthash.Vltc5vMM.dpuf "

Enhanced Ethernet Line cards are Typhoon type cards and  we ordered 
A9K-MOD160-TR
which according to Cisco falls into the Enhanced category so we should be ok:
http://www.cisco.com/c/en/us/support/docs/routers/asr-9000-series-aggregation-services-routers/116726-qanda-product-00.html

Could all these input discards be just mirrored pkts being dropped to the 
SPAN port?


>I don't remember exactly how this works, it was two years since I last did 
>this, but I seem to remember that on some plattforms if an ACL causes a 
>packet loss, it's seen as "input drop".

Really!!!????  I would love to see that reference for that.


>Also, I am curious behind your reasoning for the carrier delay settings 
>(I'd say they are backwards to what I would configure), and why are you 
>using flow control?.

The reason for the carrier delay settings was due to frequent line 
transitions that caused us to lose our BGP peer.  The trade off is to live 
for a brief hiccup and not drop the link vs dropping the link quickly 
but  then suffering a BGP reset and reload of the full routing tables.

Thanks,
Hank


>--
>Mikael Abrahamsson    email: swmike at swm.pp.se