소개
이 문서에서는 XR 라우터의 인터페이스에서 입력 삭제 문제를 해결하는 방법에 대해 설명합니다.
사전 요구 사항
요구 사항
이 문서에 대한 특정 요건이 없습니다.
사용되는 구성 요소
이 문서에서는 ASR 9000 Series 라우터, CRS Series 라우터 및 GSR 12000 Series 라우터에 대해 설명합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
배경 정보
Cisco IOS XR의 입력 삭제는 Cisco IOS의 입력 삭제와 완전히 다른 의미를 갖습니다. Cisco IOS를 Cisco IOS XR로 마이그레이션하고 show interface에서 입력 삭제 카운터를 보기 시작할 때 혼동을 줄 수 있습니다.
Cisco IOS에서 입력 삭제는 가득 찬 인터페이스 입력 대기열로 인한 것입니다. 즉, 프로세스 스위칭을 위해 너무 많은 패킷이 CPU로 전송되었으며 이를 충분히 빠르게 처리할 수 없었음을 의미합니다. 입력 대기열은 가득 차서 일부 삭제될 때까지 빌드업됩니다.
Cisco IOS XR에서는 입력 드롭에 대한 엄격한 정의가 없습니다. 따라서 기본적으로 구성 요소 개발자가 패킷을 삭제할 때 입력 삭제 카운터를 증가시킬지 여부를 결정하는 것은 구성 요소의 개발자에게 달려 있습니다. 여기서 중요한 것은 코드의 어느 시점에서 라우터가 패킷을 삭제하기로 결정한다는 것입니다. 즉, 라우터가 패킷을 전달해서는 안 되고, 라우터가 의식적으로 패킷을 삭제하기로 결정했다는 것입니다. 따라서 이는 Cisco IOS와 같은 혼잡과는 관련이 없습니다. 그러나 그것은 오히려 라우터에 수신되었고 포워딩이 안 되는 패킷이기 때문에 라우터가 그것을 폐기하기로 결정했고 그것은 아마 걱정할 이유가 될 것 같지 않습니다. 그러나 입력 삭제 카운터를 증가시키는 패킷의 종류를 완전히 이해할 때까지 걱정할 사항인지 아닌지 알 수 없으며 그렇게 간단하지 않습니다.
예:
- XR 라우터는 일부 BPDU(bridge protocol data unit) 및 UDLD 패킷을 전송하는 스위치에 연결됩니다. XR 라우터는 레이어 3 인터페이스에 스패닝 트리나 UDLD가 구성되어 있지 않으므로 이러한 프레임을 삭제하고 show interface에서 input drops 카운터를 늘립니다. 이 경우 기능이 구성되지 않아 이러한 프레임을 삭제하는 것이 올바른 작업이므로 걱정할 필요가 없습니다.
- ASR 9000에는 버그로 인해 잘못 프로그래밍된 CEF(Cisco Express Forwarding) 항목이 있으므로 유효한 인접성을 가리키지 않습니다. 이 경우 ASR 9000 LC(Line Card)의 Network Processor는 라우터가 로드 정보를 누락했음을 인식하고 인터페이스 입력 드롭 카운터에 업로드되는 NP(Network Processor) 드롭 카운터를 늘립니다.
입력 드랍이 보고되면, 문제는 이러한 드랍들이 예 1과 같은 합법적인 드랍인지, 또는 예 2와 같은 문제의 결과인지를 파악하는 것이다.
문제: 입력 드롭에서 증가
이 문서에서는 증가하는 입력 삭제의 이유와 그 이유인지 확인하는 방법을 설명합니다.
컨트롤러 삭제
Runts, FCS(Frame Check Sequence), 중단, FIFO(First Input First Output) 오버플로, SDH/SONET(Giants Packet Over SDH/SONET)이 삭제됩니다.
RP/0/RP0/CPU0:equinox#show controllers poS 0/2/0/0 framer statistics
POS Driver Internal Cooked Stats Values for port 0
===================================================
Rx Statistics Tx Statistics
------------- -------------
Total Bytes: 71346296 Total Bytes: 67718333
Good Bytes: 71346296 Good Bytes: 67718333
Good Packets: 105385 Good Packets: 67281
Aborts: 0 Aborts: 0
FCS Errors: 0 Min-len errors: 0
Runts: 0 Max-len errors: 0
FIFO Overflows: 0 FIFO Underruns: 0
Giants: 0
Drops: 0
RP/0/RP0/CPU0:equinox#
이더넷(gige, tengige...) 인터페이스의 경우 다음과 같이 확인합니다.
show controller gigabitEthernet 0/0/0/18 stats
show interface의 input drop counter와 동일한 속도로 증가하는 컨트롤러 통계에 카운터가 하나 있는지 확인합니다. 이러한 오류 카운터 중 일부는 show interface에도 있어야 합니다.
알 수 없는 대상 DMAC(Medium Access Control Address) 또는 dot1q VLAN
인터페이스 중 하나가 아닌 대상 MAC 주소가 있거나 하위 인터페이스에서 매칭하지 않는 VLAN(Virtual Local Area Network)이 있는 패킷. 알 수 없는 유니캐스트 MAC 주소의 L2 도메인에 플러딩이 있을 때 이러한 오류가 발생할 수 있습니다. 따라서 해당 L2 도메인에 연결된 XR 라우터는 컨트롤러 중 하나가 아닌 대상 MAC 주소의 프레임을 수신합니다. Cisco IOS 라우터가 GIGE 인터페이스에서 이더넷 keepalives를 전송하는 경우에도 가능합니다. 따라서 이 keepalives는 XR 라우터의 목적지 mac 주소가 없기 때문에 XR 라우터의 입력 삭제를 증가시킵니다. 또한 인터페이스가 XR 라우터에서처럼 더 많은 dot1q vlan/하위 인터페이스가 구성된 다른 디바이스에 연결된 경우 XR 라우터가 알 수 없는 dot1q 태그가 있는 프레임을 수신하게 됩니다.
CRS fixed Physical Layer Interface Module(PLIM)에서는 다음 위치에서 이러한 삭제를 찾을 수 있습니다.
RP/0/RP0/CPU0:pixies-uk#sh contr plim asic statistics interface tenGigE 0/1/0/3 location 0/1/CPU0
Wed Aug 22 16:07:47.854 CEST
Node: 0/1/CPU0
TenGigE0/1/0/3 Drop
-------------------------------------------------------------------------------
RxFiFO Drop : 0 PAR Tail Drop : 0
PAR Err Drop : 0 Invalid MAC Drop : 86
TxFIFO Drop : 0 Invalid VLAN Drop : 11
또는 tengige 또는 gige 컨트롤러 통계에서:
RP/0/RP0/CPU0:pixies-uk#sh contr ten 0/1/0/3 stats
Wed Aug 22 16:22:42.059 CEST
Statistics for interface TenGigE0/1/0/3 (cached values):
Ingress:
Input drop overrun = 0
Input drop abort = 0
Input drop invalid VLAN = 11
Input drop invalid DMAC = 0
Input drop invalid encap = 0
Input drop other = 86
참고: Cisco 버그 ID CSCub74803이 있습니다. Input drop other는 Input drop invalid DMAC 대신 최소한 CRS의 8포트 집선 고정 PLIM에서 증가합니다.
SPA(Shared Port Adapter)(CRS, XR 12000)의 경우 유효하지 않은 MAC이 있는 패킷은 SPA l2-tcam에 의해 삭제되므로 show controller TenGigE a/b/c/d all에서 이러한 삭제를 찾을 수 있습니다.
Input drop other = 107
l2-tcam Invalid DA Drops: 107
ASR 9000에서 Input(입력)은 잘못된 DMAC를 삭제하고 Input(입력)은 컨트롤러 통계에서 다른 카운터를 삭제합니다. 따라서 ASR 9000에서 이러한 삭제를 인식하는 방법은 입력 삭제를 사용하여 인터페이스를 처리하는 NP를 찾는 것입니다.
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/30 | i "input drops"
Wed Aug 22 16:55:52.374 CEST
1155 packets input, 156256 bytes, 1000 total input drops
RP/0/RSP0/CPU0:obama#sh contr np ports all location 0/0/CPU0
Wed Aug 22 16:56:01.385 CEST
Node: 0/0/CPU0:
----------------------------------------------------------------
NP Bridge Fia Ports
-- ------ --- ---------------------------------------------------
0 0 0 GigabitEthernet0/0/0/30 - GigabitEthernet0/0/0/39
1 0 0 GigabitEthernet0/0/0/20 - GigabitEthernet0/0/0/29
2 1 0 GigabitEthernet0/0/0/10 - GigabitEthernet0/0/0/19
3 1 0 GigabitEthernet0/0/0/0 - GigabitEthernet0/0/0/9
RP/0/RSP0/CPU0:obama#
인터페이스 gig 0/0/0/30이 0/0/CPU0의 NP 0에서 처리됨을 확인할 수 있습니다.
0/0/CPU0에서 NP0의 NP 카운터를 확인합니다.
RP/0/RSP0/CPU0:obama#sh contr np counters np0 location 0/0/CPU0
Wed Aug 22 16:56:19.883 CEST
Node: 0/0/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3
Read 26 non-zero NP counters:
Offset Counter FrameValue Rate (pps)
-------------------------------------------------------------------------------
22 PARSE_ENET_RECEIVE_CNT 1465 0
23 PARSE_FABRIC_RECEIVE_CNT 2793 0
24 PARSE_LOOPBACK_RECEIVE_CNT 2800 0
28 MODIFY_FABRIC_TRANSMIT_CNT 80 0
29 MODIFY_ENET_TRANSMIT_CNT 1792 0
32 RESOLVE_INGRESS_DROP_CNT 1000 0
35 MODIFY_EGRESS_DROP_CNT 1400 0
36 MODIFY_MCAST_FLD_LOOPBACK_CNT 1400 0
38 PARSE_INGRESS_PUNT_CNT 465 0
39 PARSE_EGRESS_PUNT_CNT 155 0
45 MODIFY_RPF_FAIL_DROP_CNT 1400 0
53 PARSE_LC_INJECT_TO_FAB_CNT 80 0
54 PARSE_LC_INJECT_TO_PORT_CNT 864 0
57 PARSE_FAB_INJECT_UNKN_CNT 155 0
67 RESOLVE_INGRESS_L3_PUNT_CNT 465 0
69 RESOLVE_INGRESS_L2_PUNT_CNT 464 0
70 RESOLVE_EGRESS_L3_PUNT_CNT 1400 0
93 CDP 464 0
95 ARP 1 0
109 DIAGS 154 0
221 PUNT_STATISTICS 9142 1
223 PUNT_DIAGS_RSP_ACT 155 0
225 PUNT_DIAGS_RSP_STBY 155 0
227 NETIO_RP_TO_LC_CPU_PUNT 155 0
373 L3_NOT_MYMAC 1000 0
565 INJECT_EGR_PARSE_PRRT_PIT 928 0
RP/0/RSP0/CPU0:obama#
따라서 NP 카운터의 L3_NOT_MYMAC은 라우터가 인터페이스 중 하나가 아닌 대상 MAC 주소가 있는 레이어 3 인터페이스의 프레임을 수신했음을 의미합니다. 라우터가 예상대로 삭제하며, 이는 show interface에서 입력 삭제로 보고됩니다.
ASR 9000의 하위 인터페이스에 구성되지 않은 dot1q VLAN과 함께 수신된 패킷에 대한 ASR 9000에서 입력 삭제 알 수 없는 802.1Q 카운터는 show controller gigabitEthernet 0/0/0/30 통계에서 증가하지 않습니다. 이 절차는 알 수 없는 DMAC에 대해 위와 같습니다. 어떤 NP가 인터페이스를 처리하는지 확인한 다음 이 NP 카운터를 확인합니다. 이 경우 NP 카운터 UIDB_TCAM_MISS_AGG_DROP이 증가하는 것을 볼 수 있습니다.
인식할 수 없는 상위 수준 프로토콜로 인해 삭제된 패킷
이러한 삭제에 대한 카운터가 있으므로 이를 쉽게 감지할 수 있습니다. show interface의 입력 삭제 한 줄 아래에 있습니다.
RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/18
Wed Aug 22 17:14:35.232 CEST
GigabitEthernet0/0/0/18 is up, line protocol is up
5 minute input rate 4000 bits/sec, 0 packets/sec
5 minute output rate 5000 bits/sec, 0 packets/sec
7375 packets input, 6565506 bytes, 1481 total input drops
1481 drops for unrecognized upper-level protocol
모든 입력 삭제는 인식할 수 없는 상위 레벨 프로토콜로 인한 것임을 여기서 확인할 수 있습니다.
즉, 라우터에 관심이 없는 이더넷 프로토콜로 패킷을 수신했습니다. 즉, 인접 디바이스(또는 해당 인터페이스에 연결된 레이어 2 도메인에 연결된 호스트)에 기능이 구성되어 XR 라우터에 구성되지 않은 프로토콜과 함께 프레임을 전송합니다.
예: BPDU, ISIS(Intermediate System to Intermediate System), CLNP(Connection Less Network Protocol), IPv6, UDLD, CDP(Cisco Discovery Protocol), VTP(VLAN Trunking Protocol), DTP(Dynamic Trunking Protocol), LLDP(Link Layer Discovery Protocol) 등....
이러한 기능이 XR 인터페이스에 구성되지 않은 경우 XR 상자에서 예상대로 기능을 삭제합니다. 어떤 종류의 프레임이 이 카운터를 증가시키고 있는지 알아보려면 XR 라우터에서 활성화된 기능과 인접 라우터에서 활성화된 기능(라우터 또는 스위치일 수 있음) 또는 해당 인터페이스에 연결된 레이어 2 도메인에 연결된 모든 디바이스에서 활성화된 기능을 비교해야 합니다(훨씬 더 쉬움). XR 라우터가 스위치에 연결된 경우, 인터페이스의 XR 라우터로 보내는 패킷의 해당 스위치에서 스팬을 시도하고 입력 삭제를 수행할 수 있습니다.
ASR9000/XR: 인식할 수 없는 상위 레벨 프로토콜 오류에 대한 삭제
ASR 9000의 NP 삭제
ASR 9000의 NP(Network Process)에 있는 삭제 카운터는 인터페이스에 수신된 패킷에 적용하고 삭제될 때 입력 삭제로 보고됩니다. CRS 및 XR에서 PSE(Packet Switch Engine) 삭제에 대해서는 이러한 현상이 발생하지 12000. 입력 삭제로 계산되지 않습니다.
따라서 ASR 9000에 입력 삭제가 있고 이러한 이유 중 하나와 일치하지 않는 경우 show controllers np ports all location 0/<x>/CPU0을 수행하여 입력 삭제로 인터페이스를 처리하는 NP를 찾은 다음 show contr counters np counters np<y> location 0/<x>/CPU0으로 NP 카운터를 확인합니다.
sh contr np counters np<y> location 0/<x>/CPU0과 같은 명령을 사용하여 DROP 카운터만 유지하도록 출력을 파이프할 수 있습니다 | i DROP, 그러나 이것은 경우에 따라 드롭 카운터의 이름에 DROP이 없기 때문에 위험할 수 있습니다. L3_NOT_MYMAC의 좋은 예를 본 적이 있습니다. 따라서 DROP|DISCARD|NOT|EXCD용 파이프일 수 있습니다.
인터페이스 카운터와 NP 카운터를 지우고 컨트롤러 np 카운터 np<y> 위치 0/<x>/CPU0을 지우는 것과 거의 동시에 입력 삭제와 동일한 속도로 증가하는 NP 카운터를 확인할 수 있습니다.
예를 들어, NP 카운터에서 IPV4_PLU_DROP_PKT를 가져옵니다. 이는 CEF/PLU 항목이 패킷을 삭제해야 함을 의미합니다. 기본 경로가 없고 연결할 수 없는 경로가 비활성화되어 있으므로, 기본 CEF 핸들러를 때리는 더 구체적인 경로와 일치하지 않는 패킷은 삭제 항목입니다.
NP에서 동일한 속도로 증가하는 입력 삭제를 설명할 수 있는 삭제 카운터를 발견했지만 NP 삭제 카운터가 그다지 설명이 되지 않는 경우, 이 페이지를 탐색하여 카운터의 의미를 이해할 수 있습니다.
ASR9000/XR: 패킷 삭제 문제 해결 및 NP 삭제 카운터 이해
참고: 지원 포럼의 Xander 페이지에는 1세대 라인 카드(Trident)에 대한 삭제 이유가 포함되어 있으며, 새로운 세대 라인 카드(Typhoon)에 대한 새 카운터 이름이 있습니다. 이름을 기준으로 삼지사에서와 비슷한 카운터 이름을 찾을 수 있어야 합니다.
네티오
show netio idb <int>를 수집할 수 있으며, 이렇게 하면 인터페이스 입력 삭제 및 netio 노드 삭제 카운터가 제공됩니다.
RP/0/RP0/CPU0:ipc-lsp690-r-ca-01#show netio idb gigabitEthernet 0/2/0/1
GigabitEthernet0/2/0/1 (handle: 0x01280040, nodeid:0x21) netio idb:
---------------------------------
name: GigabitEthernet0_2_0_1
interface handle: 0x01280040
interface global index: 3
physical media type: 30
dchain ptr: <0x482e0700>
echain ptr: <0x482e1024>
fchain ptr: <0x482e13ec>
driver cookie: <0x4829fc6c>
driver func: <0x4829f040>
number of subinterfaces: 4096
subblock array size: 7
DSNCNF: 0x00000000
interface stats info:
IN unknown proto pkts: 0
IN unknown proto bytes: 0
IN multicast pkts: 0
OUT multicast pkts: 0
IN broadcast pkts: 0
OUT broadcast pkts: 0
IN drop pkts: 0 <=========== cleared when added to input drop counter !!!
OUT drop pkts: 0
IN errors pkts: 0
OUT errors pkts: 0
Chains
--------------------
Base decap chain:
ether <30> <0xfd018cd8, 0x482c736c> < 0, 0>
Protocol chains:
---------------
<Protocol number> (name) Stats
Type Chain_node <caps num> <function, context> <drop pkts, drop bytes>
<snip>
<13> (mpls) Stats IN: 204 pkts, 23256 bytes; OUT: 0 pkts, 0 bytes
Encap:
mpls <25> <0xfcc7ddbc, 0x00000000> < 0, 0>
ether <30> <0xfd0189b4, 0x482c736c> < 0, 0>
l2_adj_rewrite <86> <0xfcaa997c, 0x4831a2e8> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
Decap:
pcn_input <55> <0xfd0561f0, 0x4830ba8c> < 0, 0>
q_fq_input <96> <0xfd05f330, 0x48312c7c> < 0, 0>
mpls <25> <0xfcc7b2b8, 0x00000000> < 152, 17328>
Fixup:
l2_adj_rewrite <86> <0xfcaa945c, 0x00000000> < 0, 0>
pcn_output <54> <0xfd0561f0, 0x48319f04> < 0, 0>
q_fq <43> <0xfd05f4b8, 0x48320fec> < 0, 0>
txm_nopull <60> <0xfcadba38, 0x4824c0fc> < 0, 0>
여기서 MPLS(Multi-Protocol Label Switching) 노드의 삭제는 MPLS TTL(Time To Live)이 만료되었거나(루프의 경우 또는 고객이 traceroute를 수행하는 경우) 프래그먼트가 필요하며 DF(Do Not Fragment) 비트가 설정된 것일 수 있습니다. 인터페이스 위치와 함께 debug mpls packet drop and debug mpls error를 실행하여 이 카운터를 증가시키는 패킷의 종류를 확인할 수 있습니다.
펀트된 멀티캐스트 패킷입니다. Netio IN drop pkts가 표시되지만 IN drop pkts를 설명할 수 있는 일부 삭제와 함께 netio 노드가 표시되지 않는 경우, 이를 mcast punted 패킷으로 만들 수 있으며, deb mfib netio drop을 활성화하여 어떤 종류의 패킷을 알아낼 수 있습니다
피드백