Cisco 12000 Series 인터넷 라우터에서 무시된 패킷 및 메모리 손실 문제 해결
목차
소개
이 문서에서는 Cisco 12000 Series 인터넷 라우터에서 show interfaces 명령의 출력에 무시되는 오류 수가 증가하는 이유를 해결하는 방법을 설명합니다.또한 실행 중인 슬롯<slot#> show controller의 출력에서 아무도 드롭하지 않는 증가의 문제 해결 팁을 제공합니다(frfab | tofab) qm stat 명령이러한 오류를 해결할 때 카운터가 증가하고 있으며 단순히 이력 값이 아닌지 확인합니다.
참고: show interfaces 출력에 표시되는 입력 대기열 삭제의 수가 증가하면 Cisco 12000 Series 인터넷 라우터의 입력 삭제 문제 해결에서 별도로 다룹니다.
사전 요구 사항
요구 사항
이 문서에서는 Cisco 12000 Series 인터넷 라우터 아키텍처, 특히 ToFab 및 FrFab 대기열을 이해해야 합니다.show controllers의 출력을 읽는 방법 참조 | tofab queue 명령을 참조하십시오.
사용되는 구성 요소
이 문서의 정보는 아래 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
-
Cisco 12000 Series 인터넷 라우터를 지원하는 모든 Cisco IOS® 소프트웨어 릴리스.일반적으로 12.0S 및 12.0ST 릴리스입니다.
-
모든 Cisco 12000 플랫폼은 이 문서에서 다룹니다.여기에는 12008, 12012, 12016, 12404, 12410 및 12416이 포함됩니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
증상
Cisco 12000 Series Internet Router는 분산 아키텍처를 사용하여 최적의 포워딩 성능을 보장합니다.높은 전송 속도를 지원하기 위해 인바운드 및 아웃바운드 라인 카드 모두에서 패킷 버퍼를 유지합니다.이러한 패킷 버퍼는 크기가 다르며 일반적으로 MTU(Maximum Transmission Unit) 크기의 프레임을 지원하도록 설계되었습니다.
패킷에 대한 아웃바운드 인터페이스를 결정한 후 전달 프로세서는 다음을 수행합니다.
-
포워딩 프로세서는 패킷에 대한 정보(메모리의 위치 포함)가 포함된 포인터를 아웃바운드 인터페이스의 가상 출력 대기열에 보냅니다.
-
라인 카드의 스케줄러가 스케줄러에 요청을 보냅니다.스케줄러는 부여를 발급하며 패킷은 스위칭 패브릭의 버퍼 메모리에서 아웃바운드 라인 카드로 전송됩니다.
-
아웃바운드 라인 카드는 패킷을 버퍼링합니다.
-
아웃바운드 LC의 L3 프로세서 및 관련 ASIC(Application-Specific Integrated Circuits)는 패킷을 인터페이스 밖으로 전송합니다.
아웃바운드 인터페이스가 초과 서브스크립션된 경우 초과 패킷을 버퍼링하기 시작합니다.지속적인 오버서브스크립션 기간 동안 아웃바운드 LC의 전송 큐가 채워집니다.이 경우 아웃바운드 LC에 따라 다음과 같은 상황이 발생합니다.
| 아웃바운드 LC의 엔진 유형 | 아웃바운드 혼잡 대응 | 오류 카운터 |
|---|---|---|
| 엔진 0 및 1 | 후압 신호를 보냅니다.인바운드 인터페이스가 초과 패킷을 버퍼링하기 시작합니다. | show interfaces 명령 출력에서 무시된 오류 및/또는 실행 중인 슬롯 <slot#>에서 L3 포워딩 엔진에 따라 인바운드 LC의 QM stat 명령 출력에 컨트롤러를 표시합니다. |
| 엔진 2, 3, 4 | 이그레스(egress)에 있는 초과 패킷을 삭제합니다. | 실행 슬롯 <slot#> show controller ffab QM stat 명령 출력에 아웃바운드 LC가 삭제되지 않습니다. |
l3 엔진 0, 1 및 2 인그레스 LC에 대해 무시됩니다.그러나 Engine 2 LC에서 4개, 16개 이상의 포트에 대해서는 무시된 카운터가 증가하지 않습니다.
모든 지능형 네트워킹 디바이스에서 하나 이상의 고속 인터페이스가 상대적으로 속도가 낮은 인터페이스를 제공하면 인터페이스 속도가 일치하지 않습니다.속도가 느린 아웃바운드 인터페이스는 빠른 인바운드 인터페이스에서 출력 보류 대기열로 보내는 만큼 빠른 속도로 버퍼를 반환할 수 없으므로 버퍼 반환 지연이 일부 유형의 삭제로 이어집니다.이 패킷 흐름은 아웃바운드 인터페이스가 버퍼 관리 시간의 속도로 버퍼를 반환한다는 가정을 무너뜨립니다.
인터페이스 속도가 일치하지 않는 것 외에도, CPU에서 처리할 수 있는 패킷 속도보다 도착하는 패킷의 비율이 더 크면 무시된 오류가 증가할 수 있습니다.Cisco 12000에서는 이러한 조건이 매우 드물며, 일반적으로 매우 적은 수의 패킷에서 또는 소프트웨어에서 이러한 기능을 구현하는 LC에서 ACL(Access Control List) 또는 트래픽 폴리싱 등의 CPU 집약적 기능이 활성화된 경우 이러한 문제가 발생합니다.이는 소프트웨어에 많은 기능이 구현된 Engine 0 LC의 경우입니다.그러나 이후 엔진에서는 거의 모든 기능이 하드웨어에서 구현됩니다.예를 들어, Engine 3(IP Services Engine - ISE) 및 Engine 4+ 라인 카드는 Edge 애플리케이션을 위해 설계되었으며 성능 저하 없이 하드웨어에서 향상된 IP 서비스(예: QoS)를 구현합니다.이 하드웨어의 예로는 1-Port CHOC-48 ISE, 4-Port CHOC-12 ISE, 16-Port OC-3 POS ISE, 4-Port OC-12 POS ISE, 1-Port OC-48 POS ISE 및 1-Port OC-48 POS ISE등이 있습니다.
또한 패킷이 인그레스 라인 카드에 도착하고 이 패킷을 처리하는 데 적절한 크기 패킷 버퍼를 사용할 수 없을 때마다 무시된 카운터를 증분할 수 있습니다.그러나 이 조건은 매우 드물며 이 문서에서 다루지 않습니다.
아웃바운드 인터페이스 오버서브스크립션 관리
출력 인터페이스 오버서브스크립션으로 인해 발생한 메모리 삭제와 오류를 무시하는 솔루션은 모든 L3 엔진 유형에 대해 동일하므로 버퍼 기아 방지를 방지할 수 있습니다.즉, FrFab 대기열이 채워지지 않도록 하는 메커니즘이 필요합니다.
엔진 0 및 1
간단히 말해, 패킷이 인그레스 라인 카드(LC)에 도착하고 적절한 크기의 패킷 버퍼를 사용하여 이 패킷을 처리할 수 없을 때 무시된 카운터가 증가합니다.따라서 무시된 패킷은 일반적으로 Cisco IOS 소프트웨어의 버그를 가리키지 않습니다.
다음은 Cisco 12000 Series 라우터에서 null이 아닌 무시된 카운터를 포함하는 show interfaces 명령의 샘플 출력입니다.
router#show interfaces G3/0
GigabitEthernet3/0 is up, line protocol is up
Hardware is GigMac GigabitEthernet, address is 0030.71f5.7980
(bia 0030.71f5.7980)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex mode, link type is force-up, media type is SX
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 00:00:07
Queueing strategy: fifo
Output queue 0/40, 0 drops; input queue 0/75, 0 drops
5 minute input rate 99000 bits/sec, 74 packets/sec
5 minute output rate 104000 bits/sec, 68 packets/sec
478 packets input, 71057 bytes, 0 no buffer
Received 19 broadcasts, 0 runts, 0 giants, 0 throttles
2 input errors, 2 CRC, 0 frame, 0 overrun, 25 ignored
!--- Ignored counter is > 0. Ensure it is incrementing.
0 watchdog, 53 multicast, 0 pause input
541 packets output, 139133 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
아웃바운드 LC가 엔진 0 또는 1이면 다른 LC에게 더 이상 특정 LC로 데이터를 보내지 않도록 백압력 메시지를 보냅니다.그런 다음 인바운드 인터페이스는 이 목적지 슬롯에 해당하는 ToFab 대기열의 초과 패킷을 버퍼링합니다.
Ignored 카운터가 증가하는 원인을 찾으려면 인그레스 LC의 ToFab 대기열을 확인해야 합니다.attach 명령을 사용하여 MBUS(Maintenance BUS)를 통해 LC에 연결하거나 execute-on slot <slot#> show controllers tofab queue 명령을 사용하여 ToFab 큐를 확인할 수 있습니다.이 명령을 몇 번 실행하고 다음 증상을 확인합니다.
-
비 IPC 사용 가능 대기열의 #Qelem 열에 있는 값 또는 값이 0으로 감소
-
대상 슬롯 대기열의 #Qelem 열에 있는 큰 값입니다.
엔진 2, 3, 4
최신 L3 엔진 아키텍처를 사용하는 라인 카드는 백압력 메커니즘을 사용하지 않습니다.대신 인터페이스가 오버서브스크립션되고 FrFab 대기열이 고갈되면 패킷은 이그레스 라인 카드에 도달하면 삭제됩니다.
엔진 2 LC는 더 작은 풀이 고갈될 때 다음으로 큰 버퍼 풀로 돌아가지 않습니다.폴백 메커니즘은 ToFab 측면(Rx)의 엔진 2 LC에 대해서만 구현되었습니다. 이 경우 "bump count" 카운터가 execute-on slot <slot> show controller tofab QM stat 명령의 출력에서 증가합니다.
이러한 삭제는 execute-on slot <slot#> show controllers from fap QM stat 명령의 출력에서 mem이 삭제되지 않는 것으로 계산됩니다.
Router#execute-on slot 1 show controller frfab QM stat ========= Line Card (Slot 1) ======= 174 no mem drop, 0 soft drop, 0 bump count !--- Look for an incrementing value for the "no mem drop" counter 0 rawq drops, 0 global red drops, 0 global force drops 0 no memory (ns), 0 no memory hwm (Ns) no free queue 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 multicast drops Tx Counts Interface 0 8390658710246 TX bytes, 2098330790 TX pkts, 212452 kbps, 6641 pps Interface 1 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 2 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS Interface 3 0 TX bytes, 0 TX pkts, 0 kbps, 0 PPS
FrFab 측에서 LC가 인바운드 인터페이스에 백업하거나 단순히 패킷을 삭제하는 지점까지 버퍼링하지 못하도록 하는 방법을 찾아야 합니다.
Engine 2 LC를 제외한 모든 라인 카드에 대한 간단한 해결책은 다중 인터페이스 LC의 특정 아웃바운드 인터페이스에서 사용할 수 있는 버퍼 수를 줄이는 것입니다.기본적으로 인터페이스는 조각된 모든 FrFab 버퍼를 사용할 수 있습니다.tx-queue-limit 명령을 사용하여 기본값이 아닌 값을 구성합니다.이렇게 하면 이그레스 LC가 해당 특정 포트에 대해 인터페이스 대기열에서 구성된 패킷 수보다 많은 패킷을 버퍼링할 수 없습니다.이 인터페이스에 대한 모든 FrFab 대기열을 포함하지 않도록 이 숫자를 충분히 낮게 구성해야 합니다.이 방법은 우선 순위가 높은 패킷과 낮은 패킷을 구별하지 않으며 특정 인터페이스에 대해 tail drop을 더 적극적으로 구현합니다.
엔진 3 라인 카드에는 레거시 CLI(Command Line Interface) 대신 MQC(Modular QoS CLI)를 사용해야 합니다. 이 명령은 엔진 2 기반 라인 카드에서 지원되지 않습니다.
다음은 레거시 CoS(Class of Service) 컨피그레이션을 사용하는 컨피그레이션 예입니다.
interface POS 0/0
tx-queue-limit <max Q length in packets>
다음은 MQC를 사용하는 컨피그레이션 예입니다.
policy-map TX_QUEUE_LIMIT
class class-default
queue-limit
interface POS 0/0
service-policy out TX_QUEUE_LIMIT
또 다른 해결책은 더 빠른 출력 인터페이스를 구현하여 더 큰 파이프를 만드는 것입니다.하지만 더 큰 파이프는 빠르게 가득 찰 수 있습니다.따라서 아웃바운드 LC에 QoS(Quality of Service) 메커니즘을 구현하는 것이 좋습니다.
Cisco의 WRED(Weighted Random Early Detection) 기능은 차별화되거나 지능적인 삭제 메커니즘을 구현합니다.적응형 트래픽(예: TCP 흐름)을 지원하도록 설계되었습니다.또한 대기열 크기를 모니터링하고, 계산된 평균 대기열이 구성 가능한 최소 임계값 이상으로 증가함에 따라 다양한 흐름에서 무작위로 패킷을 삭제하여 일관된 평균 대기열 크기를 유지 관리합니다.
Cisco 12000 Series에서 구현된 경우 WRED는 FrFab 대기열이 채워지지 않도록 할 수 있으며, 무엇보다도 어떤 패킷이 삭제될지 선택적입니다.엔진 0 LC는 소프트웨어에서 WRED를 지원하는 반면 엔진 1 LC는 WRED를 전혀 지원하지 않습니다.다른 L3 엔진 LC는 하드웨어에서 WRED를 지원합니다.
WRED 구성에 대한 자세한 내용은 다음 문서를 참조하십시오.
이러한 혼잡 방지 메커니즘은 TCP 기반 환경에서만 작동합니다.TCP는 트래픽 전송을 지연시켜 트래픽에 적절히(심지어 동적으로) 응답합니다.TCP가 패킷 손실에 어떻게 반응하는지에 대한 자세한 내용은 TCP가 트래픽 손실을 처리하는 방법 및 라우터가 TCP와 상호 작용하는 방법을 참조하십시오.
Cisco 12000 Series에서 지원되는 또 다른 QoS 메커니즘은 엔진 0 및 엔진 1 LC의 CAR(Committed Access Rate)을 사용하는 트래픽 폴리싱과 엔진 2 LC의 PIRC(Per Interface Rate Control)라고 하는 수정된 버전의 CAR입니다.아웃바운드 인터페이스에서 트래픽 폴리싱을 구성합니다.
인바운드 라인 카드에서 오버로드된 CPU 관리
이 상황은 매우 드문 일입니다!
execute-on slot <slot#> show controllers tofab queues 명령을 사용하여 수신 LC에서 CPU가 오버로드되었는지 확인할 수 있습니다."Raw Queue(원시 큐)" 행의 #Qelem 열에 매우 큰 숫자가 표시되면 너무 많은 패킷이 CPU에서 처리되도록 의도된 것입니다(LC 자체에 있음). CPU가 패킷의 양을 감당할 수 없기 때문에 무시된 패킷을 가져오기 시작합니다.이러한 패킷은 GRP(Gigabit Route Processor)가 아니라 LC의 CPU로 전송됩니다!
이때 CPU에 영향을 덜 받도록 이 인바운드 LC에서 트래픽을 일부 전환해야 합니다.
또한 LC 컨피그레이션에 CPU에 영향을 주는 일부 기능이 구성되어 있는지 확인해야 합니다.CAR, ACL, NetFlow와 같은 일부 기능은 소프트웨어에 구현될 때(엔진 0 LC에서만) LC의 성능을 저하시킬 수 있습니다. 이 경우, 기능을 제거하거나 Cisco IOS 소프트웨어를 동일한 기능 구현이 향상된 이후 릴리스로 업그레이드하여(예: Turbo ACL)에 따라 조치를 취해야 합니다. Cisco 12000 Series 라우터의 릴리즈 노트를 참조하여 여러 LC에 대해 구현되었거나 향상된 기능을 확인하십시오.
마지막으로, LC를 하드웨어에서 요청된 기능이 구현된 최신 LC로 교체할 수 있습니다.이는 LC의 엔진 유형에 따라 달라집니다.
다음 바로 가기 명령을 사용하여 LC의 L3 엔진 유형을 확인할 수 있습니다.
Router#show diag | i (SLOT | Engine) ... SLOT 1 (RP/LC 1 ): 1 port ATM Over SONET OC12c/STM-4c Multi Mode L3 Engine: 0 - OC12 (622 Mbps) SLOT 3 (RP/LC 3 ): 3 Port Gigabit Ethernet L3 Engine: 2 - Backbone OC48 (2.5 Gbps) ...
참고: Engine 3(IP Services Engine - ISE) 및 Engine 4+ 라인 카드는 Edge 애플리케이션을 위해 설계되었으며 성능 저하 없이 하드웨어에서 QoS와 같은 향상된 IP 서비스를 구현합니다.
설계 지침 요약
-
LC 프로세서에 ACL을 다운로드하기 전에 라우터가 ACL을 컴파일할 수 있도록 하여 성능을 최적화하는 터보 ACL을 사용합니다.
-
ACL에서 "log" 키워드를 사용하지 마십시오.
-
가능하면 발신 ACL을 사용하지 마십시오.엔진 0, 1 및 2 LC가 있는 시스템에서는 모든 ACL 처리가 인바운드 LC에서 수행됩니다.아웃바운드 ACL 필터링도 패킷의 목적지가 어떤 아웃바운드 인터페이스인지 알게 되면 인바운드 카드에서 수행됩니다.따라서 인터페이스에서 아웃바운드 ACL을 구성하면 시스템의 모든 LC에 영향을 줍니다.또한 엔진 2 LC는 수신 또는 발신 ACL을 수행할 수 있지만 하드웨어 포워딩을 수행하는 ASIC에서 동시에 수행할 수는 없습니다.인바운드 ACL과 아웃바운드 ACL을 모두 구성하면 LC는 발신 액세스 목록에 대한 CPU 기반 포워딩으로 다시 전환되어 LC의 스위칭 성능에 영향을 줍니다.그러나 Engine 3 및 Engine 4+와 같은 최신 엔진은 ACL과 같은 고급 IP 서비스 및 발신 LC에서 아웃바운드 ACL을 처리하는 데 매우 최적화되어 있습니다.
-
특정 기능이 필요한 트래픽을 하나의 LC에 할당합니다.
-
최대 패킷 전달 성능을 유지하기 위해 다른 LC 집합에 기능이 필요하지 않은 트래픽을 할당합니다.
-
고성능이 필요한 경우 더 높은 엔진 유형의 LC를 사용하십시오.
-
하드웨어 또는 마이크로코드에서 지원되는 기능을 실행할 수 있도록 백본 또는 코어 연결 LC를 설계합니다.
사례 연구
이 사례 연구에서는 슬롯 6에 있는 LC의 인터페이스에서 무시된 오류 증가를 해결하는 방법을 보여줍니다.
1단계 - 슬롯 6에서 ToFab 대기열을 확인합니다.
Router#exec slot 6 show controllers tofab queue
========= Line Card (Slot 6) =======
Carve information for ToFab buffers
SDRAM size: 134217728 bytes, address: 30000000, carve base: 30019100
134115072 bytes carve size, 4 SDRAM bank(s), 8192 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
174538/174538 buffers specified/carved
110797216/110797216 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
88964/88964 (buffers specified/carved), 50.97%, 80 byte data size
1 21120 84604 81074 262143
54076/54076 (buffers specified/carved), 30.98%, 608 byte data size
2 122270 116965 49567 262143
26165/26165 (buffers specified/carved), 14.99%, 1568 byte data size
3 164160 145355 19518 262143
!-- Out of the 26165 buffers that are carved, only 19518 are available
5233/5233 (buffers specified/carved), 2.99%, 4544 byte data size
4 172325 172088 5233 262143
IPC Queue:
100/100 (buffers specified/carved), 0.5%, 4112 byte data size
30 61 60 100 262143
Raw Queue:
31 44229 88895 0 43634
!-- The Raw Queue has a low or 0 value for the #Qelem column, indicating !-- that the CPU is not overwhelmed with packets destined to it.
ToFab Queues:
Dest
Slot
0 73769 60489 0 262143
1 7909 27395 0 262143
2 61416 71346 0 262143
3 80352 14567 0 262143
4 138236 107121 18955 262143
!-- 18955 packets are waiting for space in the outbound queues !-- on the LC in slot 4.
5 4852 48171 0 262143
6 98318 111757 0 262143
7 44229 88895 0 262143
8 0 0 0 262143
9 0 0 0 262143
10 0 0 0 262143
11 0 0 0 262143
12 0 0 0 262143
13 0 0 0 262143
14 0 0 0 262143
15 0 0 0 262143
Multicast 0 0 0 262143
2단계 - 슬롯 4에서 FrFab 큐를 확인합니다.
ToFab 대기열 출력은 슬롯 4에서 LC로 향하는 대기 중인 패킷의 수가 많으므로 이 LC에서 FrFab 대기열을 확인합니다.
Router#exec slot 4 show controllers frfab queue
========= Line Card (Slot 4) =======
Carve information for FrFab buffers
SDRAM size: 67108864 bytes, address: 20000000, carve base: 2002D100
66924288 bytes carve size, 0 SDRAM bank(s), 0 bytes SDRAM pagesize,
2 carve(s)
max buffer data size 4544 bytes, min buffer data size 80 bytes
65534/65534 buffers specified/carved
66789056/66789056 bytes sum buffer sizes specified/carved
Qnum Head Tail #Qelem LenThresh
---- ---- ---- ------ ---------
4 non-IPC free queues:
26174/26174 (buffers specified/carved), 39.93%, 80 byte data size
1 10123 4332 14515 65535
19630/19630 (buffers specified/carved), 29.95%, 608 byte data size
2 27898 37167 12279 65535
13087/13087 (buffers specified/carved), 19.96%, 1568 byte data size
3 0 52275 0 65535
!-- Zero buffers available for this pool
6543/6543 (buffers specified/carved), 9.98%, 4544 byte data size
4 60805 60804 6543 65535
IPC Queue:
100/100 (buffers specified/carved), 0.15%, 4112 byte data size
30 75 74 100 65535
Raw Queue:
31 0 80 0 65535
Interface Queues:
0 0 39413 0 65535
1 0 44192 0 65535
2 48426 58230 32111 65535
!-- Interface 2 is using half or 32111 of the carved packet buffers
3 0 41219 0 65535
3단계 - 동일한 오버서브스크립션된 인터페이스에 대한 show interfaces 명령의 출력을 비교합니다.
show controllers fap queue 출력에 표시된 오버서브스크립션 인터페이스를 동일한 인터페이스의 show interfaces 출력과 일치시킵니다.다음 출력은 출력 인터페이스 속도가 라인 속도이고 초과 서브스크립션되었음을 확인합니다.
Router#show interfaces POS 4/2
POS4/2 is up, line protocol is up
Hardware is Packet over SONET
Description: Pacbell OC3 to other ISP...
Internet address is 10.10.10.10/30
MTU 4470 bytes, BW 155000 Kbit, DLY 100 usec, rely 255/255, load 156/255
Encapsulation HDLC, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
Last input 00:00:01, output 00:00:03, output hang never
Last clearing of "show interface" counters never
Queueing strategy: FIFO Output queue 0/300, 0 drops; input queue 0/300,
0 drops
5 minute input rate 20274000 bits/sec, 6263 packets/sec
5 minute output rate 148605000 bits/sec, 28776 packets/sec
!-- The output interface rate is at line rate which means that the interface !-- is oversubscribed.
1018621328 packets input, 2339977099 bytes, 0 no buffer
Received 0 broadcasts, 1 runts, 0 giants, 0 throttles
0 parity
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
378645 packets output, 156727974 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions
4단계 - 솔루션 구현
특정 아웃바운드 인터페이스의 아키텍처에 따라 무시된 오류 증가를 해결하는 다음 단계는 이 문서의 솔루션 섹션을 참조하십시오.예를 들어, Engine 0 LC에서 일부 트래픽을 다른 인터페이스로 전환하거나, 임시적으로 이 특정 인터페이스에서 사용할 수 있는 패킷 버퍼의 수를 라인 카드의 여유 대기열에서 줄여 보십시오.다음 명령을 사용합니다.
Router(config)#int POS 4/2 Router(config-if)#tx-queue-limit 5000
Cisco IOS 소프트웨어 버그
Cisco IOS 소프트웨어 결함으로 인해 카운터가 증가하기도 합니다.이미 수정된 모든 버그를 제거하려면 기차에서 사용 가능한 최신 Cisco IOS 소프트웨어 릴리스를 실행하고 있어야 합니다.여전히 무시된 패킷이 표시되고 이 문서의 정보로 문제가 해결되지 않으면 Cisco의 TAC(Technical Assistance Center)에 문의하십시오.
피드백