유니캐스트, 멀티캐스트, 음성 트래픽 구성 혼용 Cisco 12000 Series 인터넷 라우터의 WRED 및 MDRR 예
목차
소개
이 문서에서는 다중 서비스 환경에서 RFC 2309에 설명된 WRED(Weighted Random Early Detection)를 위한 Cisco 12000 Series 라인 카드를 구성하는 방법에 대해 설명합니다. 
사전 요구 사항
요구 사항
이 문서의 독자는 다음 내용을 숙지해야 합니다.
사용되는 구성 요소
이 문서의 정보는 아래 소프트웨어 및 하드웨어 버전을 기반으로 합니다.
-
Cisco 12000 Series 인터넷 라우터를 지원하는 모든 Cisco IOS® 소프트웨어 릴리스.일반적으로 12.0S 및 12.0ST 릴리스입니다.
-
모든 Cisco 12000 플랫폼은 이 문서에서 다룹니다.여기에는 12008, 12012, 12016, 12404, 12406, 12410 및 12416이 포함됩니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
표기 규칙
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
배경 정보
Cisco 12000 Series는 고대역폭 IP 코어 네트워크를 구축하는 데 가장 많이 사용되는 플랫폼 중 하나입니다.이 플랫폼은 QoS(Quality of Service)를 구성할 수 있는 독점적인 기능을 제공합니다.
동일한 네트워크에서 서로 다른 유형의 IP 트래픽(예: VoIP - VoIP - 멀티캐스트)을 혼용하는 것이 점점 더 일반적이기 때문에 우선 순위 지정 및 제어된 삭제 동작에 대한 요구 사항이 매우 중요해지고 VoIP 같은 새로운 서비스를 시작할 때 성공과 실패 사이의 차이점이 많습니다.
다양한 유형의 IP 트래픽에 대한 네트워크 요구 사항은 이 문서의 범위를 벗어납니다.이 문서에서는 Cisco 12000 Series, 3-Port Gigabit Ethernet(3-Port GbE) 라인 카드를 포함하여 서로 다른 라인 카드에 적용되는 구성을 찾기 위해 수행한 랩 테스트에 중점을 둡니다.이 테스트의 결과는 3-Port GbE Engine 2 라인 카드가 음성, 데이터 및 멀티캐스트 트래픽이 혼합된 네트워크 환경에 적합한 것으로 나타났습니다.또한 QoS를 구성하면 혼잡한 네트워크에서 큰 차이가 있음을 입증합니다.
테스트에 사용된 우선 순위 클래스
다른 클래스에 할당된 우선 순위 값은 전체 네트워크에서 동일해야 합니다.일반 정책을 결정해야 합니다.
| 클래스 | 우선 순위 | 트래픽 |
|---|---|---|
| 사악한 교통 | 모든 식별되지 않은 네트워크 트래픽(오프넷) | |
| 네트워크 — 네트워크 | 1 | SP 네트워크 내에 있는 트래픽(온넷) |
| 인터넷 서비스 공급자(ISP) 서비스 | 2 | ISP 트래픽, SMTP, POP, FTP, DNS, 텔넷, SSH, www, https |
| SME(중소기업) | 3 | 엔터프라이즈 고객, Gold 서비스 |
| 실시간, 비음성 | 4 | TV, 실시간 게임 |
| 음성 | 5 | RTP VOIP 트래픽 |
| 네트워크 제어 메시지 | 6-7 | BGP(Border Gateway Protocol) 및 기타 제어 메시지 |
IP 패킷 색상 지정
네트워크의 코어에서 QoS를 구현하려면 서비스 공급자가 네트워크에서 전송되는 모든 IP 패킷의 우선 순위 값을 완전히 제어해야 합니다.이를 수행하는 유일한 방법은 네트워크에 들어올 때 모든 패킷을 표시하는 것이며, 고객/최종 사용자 측에서 오든 인터넷에서 오든 상관없이 이들을 구별하지 않는 것입니다.코어에는 어떠한 표시나 색칠도 해서는 안 된다.
예상 결과
이 설계의 목적은 클래스 0-3에서 진정한 WRED 동작을 갖는 것입니다. 즉, 혼잡 중에 우선순위 0개의 패킷을 삭제하기 시작하는 상황이 발생할 수 있습니다.그 후에는 혼잡이 계속되는 경우 우선 순위 1도 드롭하기 시작하고 2와 3도 우선합니다. 이 모든 내용은 아래 그래프에서 설명합니다.
음성 패킷에 대해 가능한 최저 레이턴시를 가져야 하며, 음성 및 멀티캐스트 트래픽에 대해서는 전혀 드롭되지 않아야 합니다.
네트워크 설정
컨피그레이션을 테스트하고 평가하기 위해 Agilant의 패킷 생성기와 함께 Cisco 12410을 사용했습니다.Cisco 12000 라우터는 Cisco IOS Software 릴리스 12.0(21)S1을 기반으로 엔지니어링 릴리스를 실행하고 있습니다.
3-Port GbE Engine 2 Queuing 구현
Engine 2 카드에는 일반적으로 8개의 FFAB 대기열, 1개의 짧은 대기 시간 대기열, 8개의 TFAB 대기열이 있습니다.또한 별도의 토폴로지 멀티캐스트 대기열이 있습니다.3포트 GbE 카드에는 물리적 포트당 하나의 fromfab 대기열만 있습니다.테스트에서 적용된 컨피그레이션이 더 많은 큐를 지정합니다.결과는 3포트 GbE 카드가 이 컨피그레이션을 수락하고, 사용 가능한 대기열에 큐가 자동으로 매핑됨을 보여줍니다.
Cisco IOS Software의 Engine 2 WRED 알고리즘
최소 및 최대 대기열 깊이 값을 구성할 때 Engine 2 라인 카드에서 WRED에 사용되는 알고리즘을 완전히 이해해야 합니다.코드는 구성된 최소값에 대해 중요하지 않습니다.대신 구성된 최대값에 따라 자체 수식을 사용하여 최소값을 설정합니다.
수식:
최소값 = 최대값 - (음수 결과를 생성하지 않는 최대 2의 힘)
이 테스트에 사용된 값은 ASIC(Application-Specific Integrated Circuit)에 프로그래밍된 다음과 같은 최소 값으로 나타났습니다.
| 우선 순위 | 구성된 최소 | 구성된 최대 | 최고 전력 2 | ASIC의 최소값 |
|---|---|---|---|---|
| 0 | 50 | 5000 | 4096 | 5000-4096=904 |
| 1 | 60 | 6000 | 4096 | 6000-4096=1904 |
| 2 | 70 | 7000 | 4096 | 7000-4096=2904 |
| 3 | 80 | 8000 | 4096 | 8000-4096=3904 |
이 공식을 사용하여 최소값을 계산한다는 것은 WRED 매개변수를 구성할 때 이를 고려하지 않은 경우 잘못된 패킷 처리 동작으로 끝날 수 있음을 의미합니다.다음 예에 나와 있습니다.
| 우선 순위 | 구성된 최소 | 구성된 최대 | 최고 전력 2 | ASIC의 최소값 |
|---|---|---|---|---|
| 0 | 50 | 150 | 128 | 150-128=22 |
| 1 | 75 | 225 | 128 | 225-128=97 |
| 2 | 100 | 300 | 256 | 300-256=44 |
| 3 | 125 | 375 | 256 | 375-256=119 |
즉, 값이 먼저 규칙 0, 1, 2 및 마지막 3(위)에 따라 삭제되도록 구성된 경우에도 ASIC에 값이 기록되면 실제로 우선순위 0, 우선순위 2, 우선순위 1, 우선순위 3 순으로 드롭됩니다. 마지막으로 엔진 2 카드의 ASIC에 어떤 값이 구성되었는지 확인할 수 없습니다.Engine 3 카드에 컨피그레이션을 적용하면 컨피그레이션에 표시되는 값이 실제 값(다시 계산된 최소값)이 됩니다.
QoS 컨피그레이션
QoS 컨피그레이션에 대한 자세한 내용은 Cisco 12000 Series 인터넷 라우터의 MDRR 및 WRED 이해 및 구성을 참조하십시오.
Rx CoS
rx-cos-slot 2 B2-Table rx-cos-slot 3 B2-Table rx-cos-slot 6 B2-Table
대부분의 경우 rx-cos-slot all 명령을 사용할 수 있습니다.테스트 사례에서는 토팩브 대기를 지원하지 않는 카드가 있어서 rx-cos-slot all 명령을 항상 사용할 수는 없었습니다.대신 테스트에서 사용되는 라인 카드에 슬롯 테이블을 할당했습니다.
! slot-table-cos B2-Table destination-slot all B2 multicast B2 !--- If you don't fulfill the steps above, you will not be able to reach the goal of 0 drops for Multicast traffic. With no rx-cos configured, multicast will be treated in the default queue, meaning it will drop as soon as there is congestion. !
Tx QoS
이제 tx-cos를 구성할 수 있습니다.tx qos의 이름을 선택합니다(예: "cos-queue-group B2").
삭제 동작을 구성하려는 각 우선순위 값은 별도의 임의 탐지 레이블에 매핑되어야 합니다.
precedence 0 random-detect-label 0 precedence 1 random-detect-label 1 precedence 2 random-detect-label 2 precedence 3 random-detect-label 3
MDRR(Modified Defense Round Robin)의 경우 각 우선순위를 MDRR 대기열에 매핑합니다.이 예에서는 비디오(멀티캐스트 트래픽)에 대한 대역폭을 예약하기 위해 우선순위 0-3을 동일한 MDRR 대기열에 매핑했습니다. 이 매핑은 요청된 동작을 제공합니다.
precedence 0 queue 0 precedence 1 queue 0 precedence 2 queue 0 precedence 3 queue 0 precedence 4 queue 4
음성은 우선순위 5로 표시되어 있으므로 우선순위 5가 낮은 레이턴시 대기열에 매핑됩니다.
precedence 5 queue low-latency precedence 6 queue 6 precedence 7 queue 6
이제 임의의 탐지 레이블 각각에 대해 삭제 동작을 구성해야 합니다.테스트 중에 원하는 삭제 패턴을 제공하는 값이 발견될 때까지 이러한 번호가 변경되었습니다.자세한 내용은 예상 결과 섹션을 참조하십시오.대기열 깊이는 MDRR 또는 RED-Label 대기열이 아닌 물리적 대기열에서 측정됩니다.
random-detect-label 0 50 5000 1 random-detect-label 1 60 6000 1 random-detect-label 2 70 7000 1 random-detect-label 3 80 8000 1
Cisco 12000에서는 다른 MDRR 대기열에 가중치를 부여하여 클래스 기반 CBWFQ(Weighted Fair Queuing) 동작을 생성할 수 있습니다.기본 가중치는 큐당 10입니다.MDRR 주기마다 전송된 바이트 수는 가중치 값의 함수입니다.값이 1이면 각 주기에서 1500바이트가 됩니다.값이 10이면 주기당 1500+(9*512)바이트가 됩니다."
queue 0 20 queue 4 20 queue 6 20 !
인터페이스 매핑
각 인터페이스는 WRED용으로 구성해야 합니다.이 작업은 다음 명령을 사용하여 수행됩니다.
-
터미널 구성
-
인터페이스 gig 6/0
-
tx-cos B2
삭제 없이 시작
생성된 스트림은 다른 내용을 명시하지 않는 한 다음 값을 사용합니다.
MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte 126Mb MC, 114Mb voip
이로 인해 240Mb(VoIP 및 멀티캐스트)의 백그라운드 스트림이 발생합니다.
그런 다음 같은 크기의 데이터 스트림 4개를 추가하지만 우선 순위가 0-3(스트림당 우선순위 값 1개)입니다.
각각 151MB의 4개의 데이터 스트림
이 구성에서는 총 844Mb의 대역폭을 제공합니다.아래 그래프는 패킷 삭제가 0이고 각 스트림에 대한 레이턴시가 매우 낮다는 것을 보여줍니다(음성 포함).
각각 160Mb의 4개의 데이터 스트림
이 구성에서는 총 880Mb의 대역폭을 제공합니다.아래 그래프는 우선순위 0 클래스에서 패킷이 삭제되기 시작하고 음성에 대한 레이턴시가 6ms - 밀리초로 증가했음을 보여줍니다.
각각 167MB의 4개의 데이터 스트림
이 컨피그레이션은 총 908Mb의 대역폭을 제공합니다.우선 순위 1 클래스에서도 드롭이 시작됩니다.음성 트래픽의 레이턴시는 여전히 동일합니다.
참고: 스트림이 증가하기 전에 중지되지 않았으므로 스트림 0과 1의 삭제 수 간의 차이가 누적됩니다.
각각 191MB의 4개의 데이터 스트림
총 대역폭이 증가하면 패킷도 우선순위 2 대기열에서 삭제되기 시작합니다.기가비트 이더넷 인터페이스에 도달하려는 총 대역폭은 이제 1004Mb입니다.이는 아래 그래프의 시퀀스 오류 카운터에 나와 있습니다.
각각 244MB의 4개의 데이터 스트림
우선 순위 3의 시퀀스 오류도 증가하기 시작합니다.이는 삭제가 해당 대기열에서 시작되는 첫 번째 표시입니다.GbE 인터페이스를 전송하려는 총 대역폭은 이제 1216Mb입니다.멀티캐스트(MC) 및 음성 대기열의 삭제는 여전히 0이고 음성 대기열의 레이턴시는 증가하지 않았습니다.
중지 및 시작
모든 스트림이 중지되고 카운터가 지워진 그래프를 생성하기 시작했습니다.이것은 극심한 혼잡 중에 어떻게 보이는지를 보여준다.아래에서 볼 수 있듯이, 동작은 원하는 것입니다.
모든 QoS 제거됨
혼잡 시 QoS가 실제로 성능을 개선한다는 것을 입증하기 위해 QoS가 제거되었고 인터페이스가 정체되었습니다.결과는 다음과 같습니다. 생성된 스트림은 다른 내용을 명시하지 않는 한 다음 값을 사용합니다.
MTU all three data streams 300byte, MTU voice 80byte, MTU MC 1500byte 126Mb MC, 114Mb VoIP
이로 인해 240Mb(VoIP 및 멀티캐스트)의 백그라운드 스트림이 발생합니다.
그런 다음 같은 크기의 데이터 스트림 4개를 추가하지만 우선 순위가 0-3(스트림당 우선순위 값 1개)입니다.
각각 153MB의 4개의 데이터 스트림
총 852MB가 제공됩니다.0개의 드롭이 있으며 대기 시간이 50개 미만입니다.
각각 158MB의 4개의 데이터 스트림
WRED가 적용될 때와 거의 같은 활용도로 떨어지기 시작합니다(872Mb). 이제는 14ms의 음성 패킷이 대기 시간(WRED 테스트보다 2배 이상)이 발생하며, VoIP 및 멀티캐스트를 비롯한 모든 클래스에서 동일한 방식으로 드롭됩니다.
인그레스 로드 추가
지금까지 모든 테스트에는 기가비트 이더넷 인터페이스를 통한 전송만 포함되었습니다.인터페이스를 다른 방향으로 혼잡하게 만드는 상황에서 인터페이스가 어떻게 반응하는지 확인하기 위해 다음 테스트가 완료되었습니다.
이 테스트에서는 총 1056Mb의 기가비트 이더넷 인터페이스를 로드했습니다.이로 인해 우선 순위 0-2가 삭제되고 우선 순위 3 트래픽에 대한 드롭이 없습니다.(MC와 VOIP는 동일하게 유지되었습니다. 즉, 드롭이 없습니다.) 그런 다음 패킷 생성기가 기가비트 이더넷 인터페이스를 통해 전송할 수 있었던 트래픽만큼 다른 방향으로 트래픽을 추가했습니다.결과는 매우 인상적입니다.수신 혼잡은 전송 대기열과 전혀 충돌하지 않으며, 수신 트래픽의 레이턴시는 음성 트래픽의 경우 13US보다 낮은 매우 낮습니다.
12-RP#인터페이스 g 6/0 표시
show interfaces 명령을 사용하여 기가비트 링크의 로드를 모니터링할 수 있습니다.
Router#show interfaces gig 6/0
GigabitEthernet6/0 is up, line protocol is up
Hardware is GigMac 3 Port GigabitEthernet, address is 0004.de56.c264
(bia 0004.de56.c264)
Internet address is 178.6.0.1/24
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 232/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex mode, link type is force-up, media type is SX
output flow-control is unsupported, input flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:05, output 00:00:05, output hang never
Last clearing of "show interface" counters 08:52:40
Queueing strategy: random early detection (WRED)
Output queue 0/40, 2174119522 drops; input queue 0/75, 0 drops
30 second input rate 838969000 bits/sec, 792079 packets/sec
30 second output rate 910819000 bits/sec, 464704 packets/sec
7584351146 packets input, 1003461987270 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 514 multicast, 0 pause input
11167110605 packets output, 2241229569668 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
스트림 크기 변경
테스트 결과가 모든 스트림에 대해 대역폭이 동일하기 때문에 발생하지 않는지 확인하기 위해 스트림이 서로 다른 양의 데이터를 전송하도록 변경되었습니다.또한 최대 전송 단위(MTU)를 변경하려고 시도했으므로 각 스트림에 대해 서로 다릅니다.구성된 대기열 값을 사용하면 우선 순위 0이 먼저, 1이, 2가 차례로, 마지막으로 우선 순위 3이 삭제되는 결과가 여전히 동일합니다.
10포트 기가비트 이더넷 엔진 4 라인 카드로 확인
테스트에서 VoIP 큐(Low Latency Queue)의 레이턴시가 상당히 높았기 때문에 10포트 기가비트 이더넷 엔진 4 라인 카드와 동일한 테스트를 수행했습니다.예상대로 이 라인 카드의 결과는 LLQ(Low Latency Queue)의 레이턴시에 대해 훨씬 더 우수했습니다. 그 결과는 그 하락이 어떻게 발생했는지에 관해 동일했다.LLQ의 레이턴시는 약 10us이며, 3-Port Gigabit Ethernet Engine 2 라인 카드의 레이턴시는 1:1000입니다.
피드백