이 문서에서는 모듈형 MQC(Quality of Service Command-Line Interface)의 명령을 사용하여 아웃바운드 라우터 인터페이스가 서비스 정책으로 구성될 때 hello 및 데이터베이스 설명자와 같은 라우팅 프로토콜 메시지와 기타 중요한 제어 트래픽이 대기되는 방법에 대해 설명합니다.
특히 이 문서에서는 Cisco IOS® 라우터에서 제어 패킷의 우선 순위를 지정하기 위해 사용하는 두 가지 메커니즘을 검토합니다.
필드 | 위치 | 우선 순위를 고려하는 경우 |
---|---|---|
IP 우선 순위 비트 | IP 헤더의 TOS(Type of Service) 바이트 | 네트워크를 통해 우선 순위 제공 |
pak_priority | 인터페이스 드라이버에 의해 할당되는 라우터 내의 내부 패킷 레이블 | 라우터를 통해 우선 순위 제공(홉별) |
두 메커니즘 모두 라우터 및 아웃바운드 인터페이스가 혼잡할 때 대기열 시스템에서 키 제어 패킷이 삭제 또는 삭제되지 않도록 설계되었습니다.
이 문서에 대한 특정 요건이 없습니다.
이 문서의 정보는 Cisco IOS Software 릴리스 12.2를 기반으로 합니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.
RFC(Request for Comments) 791 은 IP 패킷 헤더에 TOS 바이트를 정의합니다. RFC 2474 및 RFC 2475는 이 바이트를 DSCP(Differentiated Services Code Point) 값으로 재정의하지만, Cisco IOS 라우터는 RFC 791에 따라 TOS 바이트의 원래 IP 우선 순위 비트를 계속 사용합니다. RFC가 TOS 바이트를 정의하는 방법을 확인하십시오.
"서비스 유형은 원하는 서비스 품질(QoS)의 추상 매개변수를 나타냅니다. 이러한 매개변수는 특정 네트워크를 통해 데이터그램을 전송할 때 실제 서비스 매개변수를 선택하는 데 사용됩니다. 일부 네트워크는 서비스 우선 순위를 제공하며, 이는 일반적으로 높은 우선 순위의 트래픽이 다른 트래픽보다 더 중요하다고 간주합니다(일반적으로 로드가 높은 경우 특정 우선 순위의 트래픽만 수락함)."
다이어그램에 표시된 대로 IP 우선순위 필드는 TOS 바이트의 가장 중요한 세 비트를 차지합니다. 3개의 IP 우선 순위 비트만 TOS 바이트의 전체 값이 아니라 패킷의 우선 순위 또는 중요도를 반영합니다.
다음 표에는 우선 순위 비트 값이 나열되어 있습니다.
번호 | 비트 값 | 이름 |
---|---|---|
0 | 000 | 루틴 |
1 | 001 | 우선 순위 |
2 | 010 | 즉시 |
3 | 011 | 플래시 |
4 | 100 | 플래시 재정의 |
5 | 101 | 비평가/ECP |
6 | 110 | 네트워크 간 제어 |
7 | 111 | 네트워크 제어 |
Cisco IOS는 제어 평면의 라우팅 프로토콜 패킷에 IP 우선 순위를 6으로 할당합니다. RFC 791에 따르면 "InterNetwork Control 지정은 게이트웨이 제어 작성자에게만 사용됩니다." 특히 Cisco IOS는 다음 IP 기반 제어 패킷을 표시합니다. OSPF(Open Shortest Path First), RIP(Routing Information Protocol), EIGRP(Enhanced Interior Gateway Routing Protocol) Hello 및 keepalive입니다. 라우터를 오가는 텔넷 패킷도 IP 우선순위 값 6을 받습니다. 출력 인터페이스가 패킷을 네트워크로 전송할 때 할당된 값은 패킷과 함께 유지됩니다.
IP 우선순위 값은 네트워크를 통한 전송 내 데이터그램의 처리를 지정하지만 pak_priority 메커니즘은 라우터 내부에서 패킷을 전송하는 동안 패킷의 처리를 지정합니다.
라우터 CPU의 코어 외에도 모든 인터페이스는 네트워크 컨트롤러 또는 로컬 CPU를 사용하며, 이는 드라이버라는 특수한 소프트웨어를 실행합니다. 드라이버 코드는 인터페이스별 지침을 제공합니다.
패킷을 수신하면 인터페이스 드라이버는 소형 FIFO(first-in, first-out) 버퍼에서 I/O(input/output) 메모리의 데이터 버퍼로 패킷을 복사합니다. 그런 다음 작은 패킷 헤더를 버퍼에 연결합니다. Cisco IOS 용어로 pakType 구조라고 하는 패킷 헤더는 버퍼의 데이터 블록에 대한 주요 정보를 포함합니다. 패킷의 내용에 따라 패킷 헤더는 이더넷 캡슐화 헤더, 인터넷 프로토콜(IP) 헤더 및 TCP(Transmission Control Protocol) 헤더가 시작되는 메모리의 주소를 가리킬 수 있습니다.
Cisco IOS 소프트웨어는 패킷 헤더의 필드를 사용하여 인터페이스 큐에서 패킷의 처리를 제어합니다. 패킷 헤더에는 pak_priority 플래그가 포함되어 있습니다. 이 플래그는 대기열 시스템에 표시된 패킷의 상대적 중요도를 나타냅니다.
라우터의 코어 CPU에서 실행되는 RIP 및 OSPF 라우팅 프로세스는 IP 우선순위 6 및 pak_priority로 시작되는 모든 트래픽을 표시합니다. 반면 BGP(Border Gateway Protocol)는 TCP에 트래픽을 IP 우선순위 6으로 표시하도록 지시하지만 pak_priority는 설정하지 않습니다.
또한 Cisco IOS는 여러 유형의 비 IP 제어 패킷에 대해 낮은 삭제 가능성을 보장해야 합니다. 이러한 패킷 유형은 다음과 같습니다.
IS-IS(Intermediate System-to-Intermediate System) 라우팅 프로토콜 메시지
EIGRP(Enhanced Interior Gateway routing protocol) 메시지
PPP(Point-to-Point Protocol) 및 HDLC(High-Level Data Link Control) keepalive on serial and packet over SONET(POS) interface
ATM 인터페이스의 OAM(Operations, Administration, and Maintenance) 셀 및 ARP(Address Resolution Protocol) 메시지
이러한 트래픽은 IP가 아니므로 Cisco IOS가 IP 우선 순위 값과 매칭하여 우선순위를 지정할 수 없습니다. 대신 패킷 버퍼 헤더에서 내부 pak_priority 값만 사용합니다.
참고: Cisco Catalyst 6000/Cisco 7600 Series는 처음에 FlexWAN에서만 pak_priority 메커니즘을 지원했습니다. 이후 IP 및 비 IP 제어 패킷의 우선 순위 지정 기능이 개선되었습니다.
Cisco 7500 RSP(Route/Switch Processor) 및 로우엔드 라우터(예: Cisco 7200 및 3600 Series)와 같은 라우터는 Cisco 7500 VIP(Versatile Interface Processor)와 다른 메커니즘을 사용하여 트래픽을 라우팅하고 제어합니다. 이 표에는 두 가지 방식이 요약되어 있으며 MQC로 구성된 서비스 정책이 아웃바운드 인터페이스에 적용되었다고 가정합니다.
플랫폼 | pak_priority 메시지 대기열 |
---|---|
Cisco 7500 Series(분산 QoS 및 VIP 포함) |
|
RSP 기반 QoS 및 기타 플랫폼(Cisco 7200, 3600, 2600 Series 포함) |
|
즉, Cisco 7500 Series에서 출력 서비스 정책이 인터페이스에 연결되어 있으면 패킷은 해당 정책의 클래스에 따라 분류되고 pak_priority 패킷은 선택한 클래스 큐의 끝에 배치됩니다. pak_priority 패킷이 사용자 정의 클래스와 일치하지 않으면 class-default 대기열의 끝에 배치됩니다.
참고: 우선순위 큐잉, 사용자 지정 큐잉, 기본 인터페이스 FIFO 대기열과 같은 레거시 대기열 방법을 사용하면 비 RSP 라우터가 pak_priority 메시지를 대기열의 헤드에 대기시켜 최소 레이턴시와 최소 삭제 가능성을 모두 보장합니다.
Packet Priority Tags 및 Queuing 표에 나와 있는 것처럼 Cisco 7200, 3600 및 2600 Series와 같은 Cisco 라우터 플랫폼은 pak_priority 메시지를 클래스 기본 대기열 집합이 아닌 별도의 대기열 집합에 배치합니다.
인터페이스에 세 개의 대기열 집합이 있습니다.
소스 및 대상 IP 주소와 같은 헤더 값을 고려하는 플로우 기반 대기열 세트 2^n 실제 대기열 수는 인터페이스 또는 가상 회로의 대역폭을 기반으로 합니다. Cisco IOS 명령 참조의 fair-queue 명령에 대한 설명을 참조하십시오.
사용자가 만든 클래스에 대한 큐입니다.
linktype의 해시를 기준으로 액세스하는 대기열입니다. 예를 들어, IP 마이크로플로우는 소스 및 대상 주소와 포트, TOS 비트 및 IP 프로토콜 번호의 해시를 기반으로 공정한 대기열 시스템으로 대기열로 분류됩니다. LMI(Frame Relay Local Management Interface) 메시지는 메시지가 LMI임을 나타내는 매직 번호의 해시를 기반으로 대기됩니다. pak_priority 플래그가 있는 메시지는 이러한 개별 linktype 큐로 이동합니다.
이 표에는 대역폭이 512Kbps 이상인 인터페이스에 대한 다양한 대기열 및 대화 ID(show policy-map 인터페이스 또는 show queue 명령의 출력에 표시됨)가 나열되어 있습니다.
대화/대기열 번호 | 트래픽 유형 |
---|---|
1 - 256 | 일반 플로우 기반 트래픽 대기열. 사용자가 생성한 클래스와 일치하지 않는 트래픽은 class-default 및 flow-based 큐 중 하나와 일치합니다. |
257 - 263 | Cisco Discovery Protocol용으로 예약되었으며 내부 우선 순위 플래그가 표시된 패킷에 사용됩니다. |
264 | 우선순위 클래스에 대한 예약된 대기열(priority 명령으로 구성된 클래스) show policy-map 인터페이스 출력에서 클래스의 "Strict Priority(엄격한 우선순위)" 값을 찾습니다. 우선 순위 큐에서는 동적 큐 수와 8의 대화 ID를 사용합니다. |
265 이상 | 사용자가 만든 클래스에 대한 큐입니다. |
주: 이 테이블의 값은 구현에 따라 달라지며 변경될 수 있습니다.
IS-IS(Intermediate System to Intermediate System) 라우팅 제어 패킷은 큐잉 및 패킷 우선 순위와 관련하여 특별한 경우입니다.
IS-IS는 ISO(International Organization for Standardization)의 CLNP(Connectwithout Network Protocol)에 대한 라우팅 프로토콜입니다. CLNP의 개발자는 TCP/IP를 OSI(Open System Interconnection) 제품군이 결국 대체할 임시 프로토콜 모음으로 보았습니다. 이러한 예측 전환을 지원하기 위해 IS-IS(또는 이중 IS-IS)가 IS-IS에 대한 확장으로 생성되어 CLNS(Connectionless-mode Network Service)와 IP를 모두 라우팅할 수 있는 단일 라우팅 프로토콜을 제공합니다. 이 프로토콜은 순수 CLNS 환경, 순수 IP 환경 또는 이중 CLNS/IP 환경에서 작동하도록 설계되었습니다.
IS-IS가 TCP/IP만 라우팅하는 데 사용되는 경우에도 IS-IS는 여전히 ISO CLNP 프로토콜입니다. IS-IS가 피어와 통신하는 패킷은 CLNS PDU(protocol data unit)입니다. 즉, IP 전용 환경에서도 대기열 시스템과 Cisco IOS가 IP 우선 순위를 사용하여 CLNS 제어 메시지의 우선 순위를 지정할 수 없습니다. 대신 IS-IS 패킷은 라우터 내부의 pak_priority 메커니즘을 통해 우선 순위를 받습니다.
이 섹션에서는 Cisco 7500 Series 및 VIP의 혼잡 상황에서 제어 패킷이 삭제될 가능성을 최소화하기 위해 특별히 큐잉 전략을 설계하는 세 가지 일반적인 접근 방식을 살펴봅니다. RSP가 아닌 플랫폼에서는 기본적으로 제어 패킷을 별도의 대기열에 넣습니다.
전략 | 사용 시기 | 구성 방법에 대한 설명 |
---|---|---|
별도의 대기열에 일치시킵니다. | 가장 보수적인 전략 거의 또는 전혀 떨어뜨리지 않습니다. | 모듈형 QoS CLI를 사용하여 별도의 클래스를 구성하고 bandwidth 명령을 사용하여 혼잡 기간 동안 일치하는 트래픽에 최소 대역폭 할당을 할당합니다. bandwidth 명령으로 구성된 클래스는 IP 우선 순위가 아닌 대역폭을 기반으로 하여 스케줄링 "가중치"를 사용합니다. ATM에서 클래스 기반 가중치 공정 대기열 이해를 참조하십시오. |
공정한 대기를 사용하여 클래스 기본값에 일치시킵니다. | 대부분의 컨피그레이션에 충분합니다. 일부 제어 패킷은 혼잡이 있을 때 삭제할 수 있습니다. | Cisco IOS에서 패킷에 자동으로 할당한 IP 우선순위 6을 사용하여 패킷의 무게와 대역폭 공유에 영향을 줍니다. ATM에서 가중치 공정 대기열 이해를 참조하십시오. |
FIFO 큐잉을 사용하여 클래스 기본값과 일치시킵니다. | 혼잡한 링크는 권장되지 않습니다. 일부 제어 패킷은 혼잡이 있을 때 삭제할 수 있습니다. | 이 접근 방식에서는 IP 우선 순위를 고려하지 않습니다. VIP 기반 QoS를 사용하면 pak_priority 메시지가 FIFO 대기열의 끝 부분까지 대기됩니다. |
다음은 RIP 제어 패킷에 대해 별도의 대기열을 만드는 방법의 예입니다.
class-map match-all rp match access-group 104 ! access-list 104 permit udp any eq rip any eq rip !--- Create a class-map that matches an ACL permitting RIP. ! policy-map bandwidth class voip priority 64 class bus bandwidth 184 class RP bandwidth 8 !--- Create a policy-map (named "bandwidth") and specify !--- class RP. ! interface Serial1/0:0.1 point-to-point bandwidth 256 ip unnumbered Loopback0 ip accounting precedence input no cdp enable frame-relay class sample frame-relay interface-dlci 100 IETF !--- Apply the map-class named "sample" to the PVC. ! map-class frame-relay sample frame-relay cir 256000 frame-relay bc 2560 frame-relay mincir 256000 no frame-relay adaptive-shaping service-policy output bandwidth frame-relay fragment 160 !--- Create a frame relay map-class and apply the service !--- policy inside the map-class.
다음 방법 중 하나를 선택할 때 다음 요소를 고려하십시오.
사용된 특정 라우팅 프로토콜 및 도움말 및 데이터베이스 새로 고침에 대해 구성된 타이머 값
교환해야 하는 데이터베이스의 크기 및 업데이트/변경 또는 전체 테이블만 정기적으로 새로 고치는지 여부
인터페이스 또는 가상 회로에서 예상되는 혼잡 양
다시 말해, 혼잡이 있을 때 우선 순위가 높은 패킷을 실제로 대기시킬 가능성을 고려하십시오.
라우터에서 생성되는 트래픽은 아웃바운드 QoS 서비스 정책에 대한 특수한 경우를 나타냅니다. 로컬에서 생성된 일부 트래픽은 다른 사용자 트래픽으로 처리되어야 하며, QoS 시스템은 구성된 QoS 메커니즘을 이 트래픽에 적용해야 합니다. 이러한 트래픽의 예로는 지정된 클래스의 패킷에 의해 발생하는 동작을 측정하도록 설계된 성능 프로브가 있습니다. 로컬에서 생성된 다른 트래픽, 특히 레이어 2 keepalive 및 라우팅 프로토콜 메시지는 라우터의 기본적인 기능에 필수적이며 일부 QoS 기능의 적용을 받지 않아야 합니다. 예를 들어 평균 대기열 깊이가 하이 워터마크에 도달하면 WRED(Weighted Random Early Detection)에서 레이어 2 keepalive를 삭제해서는 안 됩니다
또한 라우터로 향하는 패킷은 신중하게 처리해야 합니다. 예를 들어, 클래스 기반 폴리싱을 적용하는 서비스 정책은 중요한 제어 메시지를 삭제하지 않도록 라우터로 향하는 패킷에 적용할 수 없습니다.
참고: 설계에 따라, RP에서 생성된 패킷은 적절하게 분류/대기열에 있더라도 모듈형 QoS CLI 카운터에서 고려되지 않습니다. 이러한 패킷은 show policy-map interface 명령 출력에서 계상되지 않습니다.
이 표에는 라우터를 오가는 패킷이 현재 주요 QoS 기능과 상호 작용하는 방식이 나열되어 있습니다.
QoS 기능 | 설명 |
---|---|
클래스 기반 표시 |
|
폴리싱 |
|
Catalyst 6000의 수퍼바이저와 MSFC(MultiLayer Switch Feature Card)에서 모두 Cisco IOS를 실행하면 RP는 라우팅 제어 패킷을 IP 우선 순위 6으로 표시합니다. 이 주석 값은 라우팅 제어 패킷을 WRR(Weighted Round Robin) 시스템의 높은 대기열, 높은 임계값에 매핑하기 위해 출력 예약과 함께 사용할 수 있습니다. QoS가 mls qos 명령을 사용하여 전역으로 활성화된 경우 MSFC에서 제공하는 라우팅 제어 패킷의 매핑은 자동으로 수행됩니다. QoS를 활성화하면 시스템은 WRED 삭제 임계값, WRR 대역폭, 대기열 제한 등의 모든 대기열 매개변수를 설정합니다. QoS를 전역적으로 비활성화하면 모든 패킷이 WRR의 낮은 대기열, 출력 예약에 대한 낮은 임계값에 매핑됩니다.
Catalyst 6000 컨피그레이션 가이드의 QoS 구성 장에서 설명한 것처럼 QoS는 이더넷 인그레스 포트에서 CoS(Layer 2 Class of Service) 값을 사용하여 분류, 마킹, 스케줄링 및 혼잡 방지를 지원합니다. 이더넷 인그레스 포트의 분류, 마킹, 스케줄링 및 혼잡 회피 기능은 레이어 3 IP 우선 순위 또는 DSCP 값을 사용하거나 설정하지 않습니다. 또한 모든 스위칭 엔진과 함께 QoS는 이더넷 이그레스 포트 스케줄링 및 레이어 2 CoS 값으로 혼잡 방지를 지원합니다. 따라서 중요한 IP 및 비 IP 패킷은 CoS 값에 매핑되어야 합니다. 이러한 값은 데이터 버스 헤더의 일부로만 내부적으로 사용되더라도 마찬가지입니다. 중요한 IP 패킷의 IP 우선순위 값은 6이 동일한 CoS 값 6에 매핑됩니다. MSFC에서 시작되는 IS-IS 패킷을 포함하는 중요한 비 IP 패킷은 pak_priority 플래그로 표시되고 그러한 플래그가 지정된 패킷은 CoS 값 6에 매핑됩니다. 이 매핑은 현재 Cisco IOS 릴리스에서 자동으로 발생합니다.
인그레스 폴리서 또는 이그레스 폴리서는 MSFC에서 소싱한 패킷을 표시하지 않으며 물리적 이더넷 인터페이스를 통해 전송할 목적지를 지정합니다.
Catalyst 6000의 QoS 구성은 이 문서의 범위를 벗어납니다. 자세한 내용은 QoS 구성 및 Catalyst LAN 및 ATM 스위치 지원 페이지를 참조하십시오.
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
15-Feb-2008 |
최초 릴리스 |