이 문서에서는 동일한 라우터에서 Cisco IOS® 소프트웨어 기능의 압축 및 QoS(Quality of Service) 활성화와 관련된 알려진 문제를 검토합니다.
Cisco IOS 소프트웨어는 WAN 대역폭 병목 현상을 완화하기 위해 WAN(Wide Area Network) 링크를 최적화하는 다양한 기능을 제공합니다.압축은 효과적인 최적화 방법이며 다음 두 가지 유형을 포함합니다.
Data Compression(데이터 압축) - 각 끝에는 링크의 전송 쪽에 있는 프레임에서 문자를 제거한 다음 수신측에서 문자를 올바르게 대체할 수 있는 코딩 체계가 제공됩니다.압축된 프레임은 더 적은 대역폭을 사용하므로 시간 단위당 더 많은 수를 전송할 수 있습니다.데이터 압축 체계의 예로는 STAC, Microsoft MPPC(Point-to-Point Compression) 및 FRF.9(Frame Relay Forum 9)가 있습니다.
헤더 압축 - OSI(Open System Interconnection) 참조 모델의 여러 레이어에서 헤더를 압축합니다.예를 들면 TCP(Transmission Control Protocol) 헤더 압축, cRTP(compressed RTP) 및 압축된 IP/UDP(Internet Protocol/User Datagram Protocol)가 있습니다.
이 문서에 대한 특정 요건이 없습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.라이브 네트워크에서 작업하는 경우, 사용하기 전에 모든 명령의 잠재적인 영향을 이해해야 합니다.
문서 표기 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
데이터 압축의 기본 기능은 네트워크 링크를 통해 전송되는 데이터 프레임의 크기를 줄이는 것입니다.프레임 크기를 줄이면 네트워크를 통해 프레임을 전송하는 데 필요한 시간이 줄어듭니다.
인터네트워킹 디바이스에서 가장 일반적으로 사용되는 두 가지 데이터 압축 알고리즘은 Stacker 및 Predictor입니다.
다음 샘플 컨피그레이션에는 프레임 릴레이 인터페이스 또는 하위 인터페이스에서 페이로드 압축을 활성화하는 두 가지 방법이 나와 있습니다.
interface Serial0/5 ip address 10.0.0.1 255.255.255.0 no ip directed-broadcast encapsulation frame-relay IETF clockrate 1300000 frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac interface Serial0/0.105 point-to-point ip address 192.168.162.1 255.255.255.0 no ip directed-broadcast frame-relay interface-dlci 105 IETF class 128k frame-relay payload-compression FRF9 stac
하드웨어 지원 데이터 압축은 소프트웨어 기반 데이터 압축과 동일한 전반적인 기능을 제공하지만, 이 계산을 기본 CPU에서 오프로드하여 압축 속도를 가속화합니다.즉,
소프트웨어 압축 - 압축은 라우터의 주 프로세서에 설치된 Cisco IOS 소프트웨어에서 구현됩니다.
하드웨어 압축 - 시스템 슬롯에 설치된 압축 하드웨어에서 압축이 구현됩니다.하드웨어 압축은 라우터에 설치된 기본 프로세서에서 압축 및 압축 해제 책임을 제거합니다.
다음 표에는 Cisco 압축 하드웨어 및 지원되는 플랫폼이 나열되어 있습니다.
압축 하드웨어 | 지원되는 플랫폼 | 참고 |
---|---|---|
SA-Comp/1 및 SA-Comp/4 서비스 어댑터(CSA) | Cisco 7000 및 7500 Series 라우터의 Cisco 7200 Series 라우터 및 2세대 VIP2(Versatile Interface Processor) | PPP(Point-to-Point Protocol) 또는 Frame Relay 캡슐화로 구성된 직렬 인터페이스를 통해 스태커 알고리즘을 지원합니다. |
NM-COMPR | Cisco 3600 Series 라우터 | FRF.9 압축 알고리즘으로 PPP 링크 및 프레임 릴레이 링크를 통한 스태커 알고리즘을 지원합니다. |
AIM-COMPR4 | Cisco 3660 Series 라우터만 해당 | LZS(Lempel-Ziv Standard) 및 MPPC 알고리즘을 지원합니다. |
compress stac와 같은 명령을 사용하여 직렬 인터페이스에서 압축을 구성하면 사용 가능한 경우 하드웨어 압축이 자동으로 활성화됩니다.그렇지 않으면 소프트웨어 압축이 활성화됩니다.compress stac software 명령을 사용하여 소프트웨어 압축을 강제로 사용할 수 있습니다.
이 섹션에서는 Cisco 레거시 PQ(priority queueing) 기능 및 압축 하드웨어의 해결된 문제에 대해 설명합니다.압축 하드웨어는 원래 PQ에서 적극적으로 패킷을 대기열에서 제거함으로써 PQ의 이점을 효과적으로 제거합니다.다시 말해, PQ는 올바르게 작동했지만 큐잉은 기능적으로 압축 하드웨어의 자체 큐(hodq, hw ring 및 compQ)로 이동했습니다. 이 큐는 FIFO(first-in, first-out)입니다. 이 문제의 증상은 Cisco 버그 ID CSCdp33759에 설명되어 있습니다(CSCdm91180의 중복 항목으로 표시됨).
이 해상도는 압축 하드웨어의 드라이버를 수정합니다.특히, 인터페이스의 대역폭에 따라 하드웨어 큐의 크기를 줄여 압축 하드웨어가 패킷을 대기열에서 빼는 속도를 조절합니다.이러한 역압 메커니즘은 패킷이 압축 하드웨어의 대기열에 유지되는 대신 복잡한 대기열에 유지됩니다.자세한 내용은 다음 버그 ID를 참조하십시오.
참고: 이러한 버그 ID에 대한 자세한 내용은 버그 툴킷(등록된 고객만 해당)을 사용하여 확인할 수 있습니다.
CSCdm91180 - 프레임 릴레이 캡슐화 및 CSA(Compression Service Adapter)에 적용됩니다.
CSCdp33759(및 CSCdr18251) - PPP 캡슐화 및 CSA에 적용됩니다.
CSCdr18251 - PPP 캡슐화 및 AIM-COMPR(비동기 인터페이스 모듈 압축)에 적용됩니다.
Cisco 3660 압축의 하드웨어 수준 대기열은 show pas caim stats 명령의 다음 샘플 출력에서 확인할 수 있습니다.하드웨어 압축 대기열에서 많은 패킷을 저장하는 경우 PQ에서 대기열에서 제거된 패킷이 이 대기열의 끝쪽에서 대기하므로 지연이 발생합니다.
Router> show pas caim stats 0 CompressionAim0 ds:0x80F56A44 idb:0x80F50DB8 422074 uncomp paks in --> 422076 comp paks out 422071 comp paks in --> 422075 uncomp paks out 633912308 uncomp bytes in --> 22791798 comp bytes out 27433911 comp bytes in --> 633911762 uncomp bytes out 974 uncomp paks/sec in --> 974 comp paks/sec out 974 comp paks/sec in --> 974 uncomp paks/sec out 11739116 uncomp bits/sec in --> 422070 comp bits/sec out 508035 comp bits/sec in --> 11739106 uncomp bits/sec out 433 seconds since last clear holdq: 0 hw_enable: 1 src_limited: 0 num cnxts: 4 no data: 0 drops: 0 nobuffers: 0 enc adj errs: 0 fallbacks: 0 no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151 Bad reqs: 0 Dead cnxts: 0 No Paks: 0 enq errs: 0 rx pkt drops: 0 tx pkt drops: 0 >dequeues: 0 requeues: 0 drops disabled: 0 clears: 0 ints: 844314 purges: 0 no cnxts: 0 bad algos: 0 no crams: 0 bad paks: 0 # opens: 0 # closes: 0 # hangs: 0
참고: CSCdr86700은 CSCdm91180에서 구현된 변경 사항을 CSA를 지원하지 않는 플랫폼에서 제거합니다.
또한 이 문제를 해결하는 동안 패킷 확장은 작은 패킷(약 4바이트)과 특정 반복 패턴(예: 0xABCDABCD 패턴의 Cisco ping)을 사용하여 해결되었습니다. 작은 패킷은 스트림의 다른 패킷과 관련될 가능성이 낮으며, 패킷을 압축하려고 하면 확장된 패킷이 발생하거나 사전이 재설정될 수 있습니다.근본적인 원인은 CSA에 사용되는 칩의 문제입니다.Cisco 버그 ID CSCdp64837은 60바이트 미만의 페이로드가 있는 패킷을 압축하지 않도록 FRF.9 압축 코드를 변경하여 이 문제를 해결합니다.
하드웨어 압축과 달리 사용자 지정, 우선 순위, 가중치 적용 공정 대기열 처리 등 소프트웨어 압축과 고급 대기열 처리는 PPP 캡슐화로 구성된 인터페이스에서 지원되지 않습니다.이 제한은 버그 ID CSCdj45401 및 CSCdk86833에 설명되어 있습니다.
제한 이유는 PPP 압축이 상태 비저장(stateless)이 아니며 압축 비율을 최적화하기 위해 데이터 스트림 위에 압축 기록을 유지 관리하기 때문입니다.압축 기록을 유지하려면 압축된 패킷을 유지해야 합니다.패킷이 큐잉 전에 압축되는 경우 단일 대기열에 넣어야 합니다.사용자 지정 및 우선 순위 큐잉이 하는 것처럼 다른 큐에 넣으면 패킷이 시퀀스에서 벗어나 압축이 중단됩니다.대체 솔루션은 최적화되지 않았으며 구현되지 않았습니다.이러한 대안에는 패킷이 대기열에서 제거될 때 압축(성능상의 이유로 허용되지 않음), 각 대기열에 대해 별도의 압축 기록 유지(지원되지 않으며 상당한 오버헤드가 수반됨), 모든 패킷에 대한 압축 기록 재설정(압축 비율에 상당히 영향)이 포함됩니다. 이를 해결하려면 HDLC(High-Level Data Link Control) 캡슐화를 구성할 수 있지만 이 컨피그레이션은 시스템 성능에 영향을 줄 수 있으므로 권장되지 않습니다.대신 하드웨어 압축을 사용합니다.
RFC 1889 는 VoIP(Voice over IP)에 대한 오디오 경로 전송을 관리하는 RTP를 지정합니다.RTP는 멀티캐스트 스트림에서 여러 발신자를 식별하고 구별하기 위해 손실된 패킷과 32비트 값을 식별하는 시퀀싱과 같은 서비스를 제공합니다.중요한 것은 QoS를 제공하거나 보장하지 않는다는 점입니다.
VoIP 패킷은 40바이트의 IP/UDP/RTP 헤더로 캡슐화된 하나 이상의 음성 코덱의 샘플 또는 프레임으로 구성됩니다.40바이트는 일반적인 20바이트 VoIP 페이로드에 비해 상대적으로 큰 오버헤드, 특히 저속 링크에 대한 오버헤드입니다.RFC 2508 은 IP/UDP/RTP 헤더를 대부분의 패킷에 대해 2바이트로 줄이거나 체크섬을 사용하는 4바이트로 줄이도록 설계된 압축된 RTP(cRTP)를 지정합니다.이 문서에 정의된 압축 알고리즘은 RFC 1144 에 설명된 대로 TCP/IP 헤더 압축을 설계하는 데 크게 사용됩니다.
RFC 2508은 실제로 cRTP의 두 가지 형식을 지정합니다.
CR(Compressed RTP) - IP, UDP 및 RTP 헤더가 일관되게 유지되는 경우에 사용됩니다.세 헤더 모두 압축됩니다.
CU(Compressed UDP) - RTP 타임스탬프에 큰 변경 사항이 있거나 RTP 페이로드 유형이 변경될 때 사용됩니다.IP 및 UDP 헤더는 압축되지만 RTP 헤더는 압축되지 않습니다.
Cisco IOS Software 릴리스 12.1(5)T는 Cisco 2600, 3600 및 7200 Series 라우터에서 PVC(Frame Relay Permanent Virtual circuit)를 통한 압축의 몇 가지 개선 사항을 도입했습니다.이러한 개선 사항은 다음과 같습니다.
Cisco IOS 릴리스 12.1(5)T 이전 | Cisco IOS 릴리스 12.1(5)T 및 12.2 |
---|---|
음성 품질을 보장하기 위해 필요한 저속 WAN 에지 프래그먼트화 방법이 하드웨어 압축 인터페이스에서 작동하지 않았습니다.MLPPP/LFI, FRF.11 Annex C 및 FRF.12를 포함하는 이러한 단편화 방법은 소프트웨어 기반 압축과 함께 작동합니다. | 조각화(FRF.12 또는 LFI(Link Fragmentation and Interleaving))는 하드웨어 압축과 함께 지원됩니다.또한 FRF.12 및 FRF.11 Annex-C Fragmentation은 동일한 PVC에서 FRF.9 하드웨어 압축을 지원합니다.LLQ(Low Latency Queueing)가 있는 우선순위 대기열의 음성 패킷은 FRF.9 압축기 엔진을 우회합니다.데이터 패킷은 압축됩니다. |
FRF.9 압축은 IETF-encap PVC에서만 지원됩니다. | 동일한 PVC에서 cRTP 및 FRF.9 압축이 지원됩니다.FRF.9 압축은 Cisco 및 IETF(Internet Engineering Task Force) 캡슐화로 구성된 PVC에서 지원됩니다. |
cRTP는 Cisco 캡슐화로만 구성된 프레임 릴레이 PVC에서 지원됩니다. | cRTP는 Cisco 캡슐화된 PVC에서만 계속 지원됩니다. |
다음 표에는 cRTP 및 Cisco IOS QoS 기능에 대한 알려진 문제가 나열되어 있습니다.이 목록은 게시 시점에 정확합니다.자세한 내용은 Cisco IOS 소프트웨어 버전에 대한 릴리스 정보를 참조하십시오.
버그 ID | 설명 |
---|---|
CSCdv73543 | 모듈형 QoS CLI의 명령을 사용하는 계층적 QoS 정책이 아웃바운드 인터페이스에 적용되고 2레벨 폴리서를 지정하는 경우, 구성된 트래픽 속도가 예상보다 적을 수 있습니다.한 레벨의 패킷에 대해 수행된 작업이 두 번째 레벨의 패킷과 다를 때 문제가 발생합니다.예를 들어, 첫 번째 레벨에서 conform하고 두 번째 레벨에서 exceed를 입력합니다.정책의 예는 다음과 같습니다. policy-map test-policer class class-default police 10000 1500 1500 conform-action transmit exceed-action transmit service-policy inner-police ! policy-map inner-police class prec5 police 20000 1500 1500 conform-action transmit exceed-action transmit |
CSCdt52094 | 프레임 릴레이를 통해 LLQ(Low Latency Queuing)를 사용할 경우 예기치 않은 패킷 드랍이 나타날 수 있습니다.이 문제는 대기열 시스템이 cRTP의 대역폭 이익을 고려하지 않았기 때문에 발생했습니다. |
CSCds43465 | 원래 cRTP는 큐잉 후 발생했습니다.그 결과, 큐잉(잠재적으로)은 실제로 와이어에서 전송된 패킷보다 훨씬 큰 패킷을 확인했습니다.이 동작은 이 버그로 변경됩니다.이제 큐잉은 압축된 패킷을 고려합니다.이 변경을 통해 압축된 데이터 속도를 기반으로 CBWFQ를 사용하여 대역폭 문을 구성할 수 있습니다. |