이 문서에서는 출력 속도를 제한하는 트래픽 형성과 트래픽 폴리싱 간의 기능적 차이점에 관해 설명합니다.
이 문서에 대한 특정 요건이 없습니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.
이 문서에서는 트래픽 셰이핑과 폴리싱의 기능적 차이를 설명합니다. 두 기능 모두 트래픽 출력 속도를 제한합니다. 두 메커니즘 모두 토큰 버킷을 트래픽 측정기로 사용하여 패킷 속도를 측정합니다. 토큰 버킷에 대한 자세한 내용은 토큰 버킷이란 무엇인지를 참조하십시오
이 문서의 개념은 Cisco QoS 설계를 이해하는 데 도움이 됩니다. 트래픽 셰이핑 및 트래픽 정책은 최대 트래픽 속도를 적용하고 정체를 관리하는 데 계속 사용됩니다. 신규 구축의 경우, Cisco에서는 플랫폼에서 지원하는 경우 MQC(Modular QoS Command-Line) 클래스 기반 쉐이핑 및 클래스 기반 폴리싱을 사용할 것을 권장합니다. GTS(Generic Traffic Shaping), FRTS(Frame Relay Traffic Shaping), CAR(Committed Access Rate) 및 rate-limit 명령과 같은 레거시 메커니즘은 기록 컨텍스트에 포함되거나 플랫폼별 토론을 지원합니다.
트래픽 폴리싱은 버스트를 전파합니다. 트래픽 속도가 설정된 최대 속도에 도달하면 초과 트래픽은 삭제(또는 다시 마킹)됩니다. 그 결과, 출력 속도는 톱니 모양으로 표시됩니다. 폴리싱과 달리 트래픽 셰이핑은 초과 패킷을 대기열에 유지한 다음, 시간 증가에 따라 나중에 전송할 수 있도록 초과 패킷을 예약합니다. 트래픽 쉐이핑의 결과는 평활화된 패킷 출력 속도입니다.
다음 다이어그램은 두 트래픽 옵션의 주요 차이점을 보여줍니다.
정책 VS 형성
셰이핑은 큐가 있고 지연된 패킷을 버퍼링할 충분한 메모리가 있음을 의미합니다. 그러나 폴리싱은 그렇지 않습니다. 대기열은 아웃바운드 개념입니다. 인터페이스를 떠나는 패킷은 대기 상태가 되며 셰이핑될 수 있습니다. 인터페이스의 인바운드 트래픽에는 폴리싱만 적용할 수 있습니다. 셰이핑을 활성화할 때 충분한 메모리가 있는지 확인합니다. 또한 셰이핑은 지연된 패킷의 나중에 전송을 예약하는 기능을 필요로 합니다. 이 예약 기능을 사용하면 셰이핑 대기열을 다른 대기열로 구성할 수 있습니다. 이 기능의 예로는 CBWFQ(Class Based Queuing Weighted Fair) 및 LLQ(Low Latency)Queuing가 있습니다.
참고: 트래픽 셰이핑과 트래픽 정책은 모두 구성된 트래픽 속도를 적용합니다. 셰이핑은 이그레스 대기열 메커니즘입니다. 폴리싱은 플랫폼 및 기능 지원에 따라 인바운드 또는 아웃바운드에 적용될 수 있습니다.
다음 표에는 적절한 트래픽 솔루션을 선택하는 데 도움이 되는 쉐이핑과 폴리싱의 차이점이 나열되어 있습니다.
| 트래픽 셰이핑 | 트래픽 폴리싱 | |
|---|---|---|
| 기본 동작 | 커밋된 속도 이상의 초과 패킷을 버퍼하고 대기시킵니다. | 커밋된 속도를 초과하는 초과 패킷을 삭제(또는 설명)합니다. 버퍼링하지 않습니다.* |
| 토큰 새로 고침 빈도 | 토큰은 각 Tc 간격으로 주기적으로 보충됩니다. 각 간격의 시작 시 쉐이퍼는 Bc 토큰을 구성된 버킷 한도까지 추가합니다. Tc는 플랫폼별 제한에 의해 제한됩니다. | 토큰은 패킷 도착 사이에 경과된 시간을 기준으로 보충됩니다. 폴리서는 추가할 토큰 수를 계산합니다. ((t - t1) * policer_rate_bps) / 8, 여기서 t - t1은 이전 패킷 이후의 시간입니다. |
| 토큰 값 | bps(bits per second) 단위로 구성됩니다. | 바이트 단위로 구성됩니다. |
| 컨피그레이션 옵션 |
|
|
| 일반 방향 | 아웃바운드 | 인바운드 또는 아웃바운드, 플랫폼에 따라 다름 |
| 버스트 | 최소 8개 시간 간격으로 버스트 및 출력 속도를 제어합니다. 토큰 버킷 계량을 사용하고 초과 패킷을 큐잉합니다. 대기열에 있는 패킷은 시간이 지남에 따라 해제되므로 누출된 버킷과 유사한 매끄러움 효과가 생성됩니다. | 구성된 버스트 제한 내에서 버스트를 허용합니다. 전송 속도를 원활하게 하기 위해 패킷을 버퍼링하지 않습니다. |
| 장점 | 초과 패킷이 버퍼링되므로 초과 패킷을 삭제할 가능성이 적습니다. (큐 길이까지 패킷을 버퍼링합니다. 초과 트래픽이 높은 속도로 지속되는 경우 드롭이 발생할 수 있습니다.) 일반적으로 삭제된 패킷으로 인한 재전송을 방지합니다. | 패킷 삭제를 통해 출력 속도를 제어합니다. 이로 인한 지연 queuing방지 |
| 단점 | 특히 대기열이 깊기 때문에 queuing지연이 발생할 수 있습니다. |
과도한 패킷(구성된 경우)을 삭제하고, TCP 창 크기를 줄이며, 영향을 받는 트래픽 스트림의 전체 출력률을 줄입니다. 버스트 크기가 지나치게 크면 과도한 패킷이 드롭되고 특히 TCP 기반 플로우의 경우 전반적인 출력 속도가 저하될 수 있습니다. |
| 선택적 패킷 리마킹 | 아니요 | 예. 구성된 MQC 폴리서 작업 및 플랫폼 지원에 따라 선택적으로 IP 우선 순위 또는 DSCP 작업을 비롯한 패킷을 전송, 삭제 또는 표시할 수 있습니다. |
참고: 폴리싱은 버퍼를 적용하지 않지만 구성된 대기열 지정 메커니즘은 물리적 인터페이스에서 직렬화를 기다리는 동안 대기해야 하는 일치하는 패킷에 적용됩니다.
셰이핑과 폴리싱의 주요 차이점은 토큰이 보충되는 속도입니다. 셰이핑과 폴리싱은 모두 토큰 버킷 메타포를 사용합니다. 토큰 버킷 자체에는 폐기 또는 우선순위 정책이 없습니다.
토큰 버킷 기능:
토큰이 일정한 속도로 버킷에 담깁니다.
각 토큰은 소스에서 네트워크로 특정 비트 수를 보낼 수 있는 권한을 부여합니다.
패킷 하나를 전송하려면 트래픽 조절기는 해당 패킷 크기에 대해 표시된 것과 동등한 수의 토큰을 버킷에서 제거할 수 있어야 합니다.
버킷에 패킷을 전송할 수 있는 충분한 토큰이 없는 경우, 패킷은 버킷에 충분한 토큰이 있을 때까지 대기하거나(쉐이퍼의 경우), 패킷이 폐기되거나 아래로 표시됩니다(폴리서의 경우).
버킷 자체에는 지정된 용량이 있습니다. 버킷의 용량이 가득 차면 도착하는 새 토큰은 폐기되며 이후 패킷에서는 사용할 수 없습니다. 따라서 언제든지 소스가 네트워크로 전송할 수 있는 최대 버스트는 버킷의 크기와 거의 비례합니다. 토큰 버킷은 재물을 허용하지만 그것을 제한한다.
셰이핑은 bps(bits per second) 값을 사용하는 시간 간격에 따라 토큰 버킷을 증가시킵니다. 쉐이퍼는 다음 공식을 사용합니다.
Tc = Bc/CIR (in seconds)
이 방정식에서는
Bc: 커밋된 버스트. 한 시간 간격 동안 전송할 수 있는 트래픽의 양입니다.
CIR: 커밋된 정보 전송률. 쉐이퍼 또는 폴리서가 적용하는 평균 트래픽 비율입니다.
Tc: 커밋된 시간 간격 구성된 CIR을 유지하면서 셰이퍼가 커밋된 버스트를 보내는 데 사용한 시간 간격(초)입니다.
Tc의 범위는 10ms에서 125ms 사이입니다. DTS(Distributed Traffic Shaping)가 있는 일부 레거시 플랫폼의 경우 최소 Tc는 4ms입니다. 라우터는 내부적으로 CIR 및 Bc 값을 기반으로 이 값을 계산합니다. Bc/CIR이 125 ms 미만일 경우 해당 식에서 계산된 Tc를 사용한다. Bc/CIR이 125ms 이상인 경우 Cisco IOS에서 트래픽 흐름이 더 작은 간격으로 더 안정적일 수 있다고 판단할 경우 내부 Tc 값을 사용합니다. 라우터에서 Tc에 대한 내부 값을 사용할지 또는 명령줄에서 구성한 값을 사용할지를 확인하려면 show traffic-shape 명령을 사용합니다.
트래픽 출력 표시
Be(Excess Burst)가 0과 다른 값으로 구성된 경우 쉐이퍼는 최대 Bc + Be까지 토큰을 버킷에 저장할 수 있게 합니다. 토큰 버킷이 도달할 수 있는 최대 값은 Bc+Be이며 오버플로 토큰은 삭제됩니다. 버킷에 Bc 토큰 이상을 갖는 유일한 방법은 하나 이상의 Tc 동안 모든 Bc 토큰을 사용하지 않는 것이다. 토큰 버킷은 모든 Tc에 Bc 토큰으로 보충되기 때문에 나중에 Bc+Be까지 사용할 수 있도록 사용하지 않은 토큰을 누적할 수 있다.
이와 달리 클래스 기반 정책 및 속도 제한 정책은 패킷 도착 사이의 경과 시간을 기반으로 토큰을 보충합니다. 패킷이 도착하면 폴리서는 이전 패킷 이후의 시간 및 구성된 폴리서 속도에서 추가할 토큰 수를 계산합니다. 특히 토큰 도착율은 다음과 같이 계산됩니다.
Tokens added = ((t - t1) * policer_rate_bps) / 8 bytes
즉, 패킷의 이전 도착이 t1이고 현재 시간이 t이면, 토큰 도착률을 기준으로 t-t1 바이트의 값으로 버킷을 업데이트한다.
참고: 트래픽 폴리서는 바이트로 지정된 버스트 값을 사용하며, 이전 공식은 비트에서 바이트로 변환합니다.
다음은 8000bps의 CIR(또는 폴리서 레이트)와 1000바이트의 일반 버스트를 사용하는 예입니다.
Router(config)#policy-map police-setting Router(config-pmap)#class access-match Router(config-pmap-c)#police 8000 1000 conform-action transmit exceed-action drop
토큰 버킷은 1000바이트에서 가득 차기 시작합니다. 450바이트 패킷이 도착하면 토큰 버킷에서 사용할 수 있는 바이트가 충분하기 때문에 패킷이 일치합니다. Conform 작업(전송)은 패킷에 의해 수행되며 토큰 버킷에서 450바이트가 제거됩니다(그리고 550바이트는 남겨둡니다). 다음 패킷이 0.25초 후에 도착하면 다음 공식에 따라 250바이트가 토큰 버킷에 추가됩니다.
(0.25 * 8000)/8
버킷 가득 참 시작:
첫 번째 패킷 도착:
계산: 1000 - 450 = 550바이트 남음
다음 패킷은 0.25초 후에 도착합니다.
(0.25×8000)/8 = 250바이트
새로 고침 후 버킷:
계산: 550 + 250 = 800바이트
계산에서는 토큰 버킷에 800바이트(폴리서 버킷에 남아 있는 토큰)를 남깁니다. 다음 패킷이 900바이트이면 패킷이 초과되고 초과 작업(삭제)이 수행됩니다. 토큰 버킷에서 가져온 바이트가 없습니다.
Cisco IOS®는 다음 트래픽 셰이핑 방법을 지원합니다.
모든 트래픽 셰이핑 방법은 구현 면에서 유사하지만, CLI(Command-Line Interface)는 다소 다르며, 서로 다른 유형의 큐를 사용하여 지연된 트래픽을 포함하고 셰이핑합니다. Cisco에서는 모듈형 QoS CLI로 구성되는 클래스 기반 셰이핑 및 분산 셰이핑을 권장합니다.
다음 다이어그램은 QoS 정책이 어떻게 트래픽을 클래스로 정렬하고 구성된 쉐이핑 속도를 초과하는 패킷을 큐잉하는지 보여줍니다.

Cisco IOS는 다음 트래픽 폴리싱 방법을 지원합니다.
클래스 기반 폴리싱을 구성하는 방법에 설명된 대로 두 메커니즘은 중요한 기능적 차이가 있습니다. Cisco에서는 QoS 정책이 적용될 때 클래스 기반 정책 및 모듈형 QoS CLI의 기타 기능을 권장합니다.
Police 명령을 사용하여 트래픽 클래스에 지정된 최대 속도가 있어야 하며, 이 속도를 초과하면 즉시 조치를 취해야 합니다. 즉, police 명령을 사용하면 shape 명령의 경우처럼 패킷을 버퍼링한 후 나중에 전송하는 옵션이 아닙니다.
또한 폴리싱을 통해 토큰 버킷은 패킷이 적용된 속도를 초과하는지 또는 준수하는지 여부를 결정합니다. 두 경우 모두 폴리싱은 구성 가능한 작업을 구현합니다. 여기에는 IP 우선 순위 또는 DSCP(Differentiated Services Code Point)가 포함됩니다.
다음 다이어그램은 일반적으로 QoS 기능이 적용되는 혼잡 지점에서 트래픽 폴리싱의 일반적인 적용을 보여줍니다.

shape 및 police 명령은 구성된 최대 속도로 트래픽을 제한합니다. MQC에서는 플랫폼별 구문이 다르게 명시되지 않는 한 셰이프 평균 및 폴리스에 대해 구성된 속도는 bps로 지정됩니다. 중요한 것은 어느 메커니즘도 혼잡 기간 동안 최소 대역폭 보장을 제공하지 않는다는 것입니다. 이러한 보장을 제공하려면 bandwidth 또는 priority 명령을 사용합니다.
계층적 정책은 두 가지 서비스 정책, 즉 상위 정책을 사용하여 트래픽 집계에 QoS 메커니즘을 적용하고 하위 정책을 사용하여 트래픽 집계의 플로우 또는 하위 집합에 QoS 메커니즘을 적용합니다. 하위 인터페이스 및 터널 인터페이스와 같은 논리적 인터페이스에는 상위 레벨의 트래픽-limiting 기능과 하위 레벨의 큐잉이 포함된 계층적 정책이 필요합니다. 트래픽-limiting 기능은 초과 패킷에서 볼 수 있듯이 출력 속도를 줄이고 혼잡을 queuing 일으킵니다.
다음 컨피그레이션은 최적화되지 않으며, 트래픽이 최대 속도로 집계될 때의 경찰 대 shape 명령 limiting 간의 차이를 설명하기 위해 표시됩니다. 이 컨피그레이션에서는 police 명령이 패킷의 크기 및 conform 및 exceed 토큰 버킷에 남아 있는 바이트 수에 따라 하위 클래스에서 패킷을 전송합니다. (트래픽 폴리싱을 참조하십시오.) 그 결과, 경찰 기능이 우선 순위 기능이 보장한 것을 무시하므로 VoIP(Voice over IP) 및 IP(Internet Protocol) 클래스에 부여되는 속도를 보장할 수 없습니다.
그러나 shape 명령을 사용하면 계층적 큐잉 시스템이므로 모든 보증이 이루어집니다. 다시 말해, 제공된 로드가 셰이프 속도를 초과하면 VoIP 및 IP 클래스의 속도가 보장되고 클래스 기본 트래픽(하위 수준)에 어떤 삭제도 발생합니다.
class-map match-all IP
match ip precedence 3
class-map match-all VoIP
match ip precedence 5
!
policy-map child
class VoIP
priority 128
class IP
priority 1000
!
policy-map parent
class class-default
police 3300000 103000 103000 conform-action transmit exceed-action drop
service-policy child
이전 컨피그레이션이 타당하기 위해서는 폴리싱을 셰이핑으로 교체해야 합니다. 예를 들면 다음과 같습니다.
policy-map parent
class class-default
shape average 3300000 103000 0
service-policy child
show policy-map interface <interface>를 사용하여 구성된 정책, 클래스 카운터, 제공된 속도, 삭제 카운터, 셰이핑 속도, 큐 깊이 및 정책 준수/초과/위반 카운터를 확인합니다.
Router#show policy-map interface gigabitEthernet 0/0/2
GigabitEthernet0/0/2
Service-policy output: parent
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
Queueing
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
shape (average) cir 3300000, bc 103000, be 0 target shape rate 3300000
Service-policy : child
queue stats for all priority classes:
Queueing
queue limit 512 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
Class-map: VoIP (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 5
Priority: 128 kbps, burst bytes 3200, b/w exceed drops: 0
Class-map: IP (match-all)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: ip precedence 3
Priority: 1000 kbps, burst bytes 25000, b/w exceed drops: 0
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
queue limit 64 packets
(queue depth/total drops/no-buffer drops) 0/0/0
(pkts output/bytes output) 0/0
앞의 예는 의도적으로 최적이 아니며 계층적 QoS 정책에서 폴리싱과 쉐이핑 간의 차이를 설명하기 위해서만 제공됩니다. 권장 QoS 설계에서 priority 명령은 일반적으로 음성과 같이 대기 시간에 민감한 실시간 트래픽에 예약됩니다. 최소 대역폭 보장이 필요한 비실시간 클래스는 일반적으로 bandwidth 명령을 CBWFQ와 함께 사용합니다.
이 접근 방식은 LLQ 및 CBWFQ에 대한 Cisco QoS 설계 지침에 부합합니다. LLQ는 지연에 민감한 트래픽에 대해 엄격한 우선 순위 처리를 제공하는 반면, CBWFQ는 혼잡 중에 다른 트래픽 클래스에 대한 대역폭 보장을 제공합니다. 따라서 이 예의 IP 클래스는 엄격한 우선 순위 처리가 명시적으로 필요한 트래픽을 전달하지 않는 한 우선 순위가 아닌 대역폭으로 더 잘 표현됩니다.
policy-map child
class VoIP
priority 128
class IP
bandwidth 1000
| 개정 | 게시 날짜 | 의견 |
|---|---|---|
6.0 |
21-Jul-2026
|
재인증. |
4.0 |
07-Sep-2023
|
업데이트된 브랜딩 요구 사항, SEO, 문법 및 서식. |
3.0 |
26-Sep-2022
|
재인증 |
1.0 |
15-Feb-2002
|
최초 릴리스 |