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: [email protected]
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
