At 11:30 15/05/2015 -0700, Andrew Miehs wrote:
Thanks for all the feedback and links. The person who came up with the
solution was Tom:
" ipv4 unreachables disableâ
I believe that XR counts packets that it needs to respond to with an
unreachable as a input drop, since these are disabled.
Once I disabled this command I stopped seeing input drop counters on our
interface increment.
We disabled this command and the discards disappeared immediately.
Regards,
Hank
Discards is probably acl/ control plane acl, full buffers on egress port/
fabric.
Not familiar with the platform so cant provide more info.
Sent from a mobile device
> On 15 May 2015, at 01:02, Alexandr Gurbo <[email protected]> wrote:
>
> Hello,
>
> Check you fiber connection.
>
>
> On Thu, 14 May 2015 22:04:35 +0300
> Hank Nussbacher <[email protected]> wrote:
>
>> We have an ASR 9010 running IOS-XR v 5.1.3. We see a high level of input
>> discards:
>>
>> TenGigE0/1/1/7 is up, line protocol is up
>> Interface state transitions: 25
>> Layer 1 Transport Mode is WAN
>> MTU 9028 bytes, BW 10000000 Kbit (Max: 10000000 Kbit)
>> reliability 255/255, txload 13/255, rxload 99/255
>> Encapsulation ARPA,
>> Full-duplex, 10000Mb/s, link type is force-up
>> output flow control is on, input flow control is on
>> Carrier delay (up) is 100 msec, Carrier delay (down) is 4000 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 1d13h
>> 30 second input rate 3886868000 bits/sec, 392410 packets/sec
>> 30 second output rate 527057000 bits/sec, 154557 packets/sec
>> 55223825999 packets input, 63505398737673 bytes, 116320028 total
>> input drops
>> 0 drops for unrecognized upper-level protocol
>> Received 111 broadcast packets, 1499584 multicast packets
>> 0 runts, 0 giants, 0 throttles, 0 parity
>> 10 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
>>
>> 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.
>>
>> Thanks,
>> Hank
>>
>> _______________________________________________
>> cisco-nsp mailing list [email protected]
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
> --
> Alexandr Gurbo
> _______________________________________________
> cisco-nsp mailing list [email protected]
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
