이 문서에서는 프레임 릴레이 트래픽 셰이핑을 위한 샘플 컨피그레이션을 제공합니다.
이 문서에 대한 특정 요건이 없습니다.
Cisco IOS® Software 릴리스 11.2부터 프레임 릴레이 트래픽 셰이핑이 지원됩니다.
Cisco 7200 라우터 및 하위 플랫폼에서 지원됩니다.분산 트래픽 셰이핑은 Cisco 7500 라우터, 7600 라우터 및 FlexWAN 모듈에서 지원됩니다.
문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참조하십시오.
프레임 릴레이 트래픽 셰이핑의 일반적인 구현은 다음과 같습니다.
고속-저속 회로 불일치:여기에는 두 가지 가능성이 있습니다.
허브 사이트에는 클라우드에 T1 회선이 있는 반면 원격 사이트의 속도는 56Kbps입니다. 이 경우, 원격 측 액세스 속도를 초과하지 않도록 허브 사이트의 속도를 제한해야 합니다.
허브 사이트에는 클라우드에 단일 T1 회선이 있고, 원격 사이트에는 클라우드에 전체 T1 회선이 있으므로 동일한 허브 사이트에 연결됩니다.이 경우 허브를 오버런하지 않도록 원격 사이트의 속도를 제한해야 합니다.
초과 서브스크립션:예를 들어, PVC(Permanent Virtual Circuit)의 보장 속도가 64Kbps이고 액세스 속도가 양쪽 끝에서 128Kbps인 경우 혼잡이 없을 때 보장 속도를 초과하여 버스트할 수 있으며, 혼잡이 있을 때 보장 속도로 다시 폴백할 수 있습니다.
QoS(Quality of Service):FRF.12 프래그먼트화 또는 낮은 레이턴시 대기열 기능을 구현하여 더 나은 서비스 품질을 얻으려면 VoIP over Frame Relay with Quality of Service를 참조하십시오.
참고: 액세스 속도는 프레임 릴레이에 연결하는 인터페이스의 물리적 회선 속도입니다.보증율은 PVC에 대해 Telco가 제공한 CIR(commit information rate)입니다.CIR 또는 minCIR을 액세스 속도로 설정하면 출력이 삭제되어 트래픽이 조절될 수 있으므로 피해야 합니다.그 이유는 셰이프 속도가 플래그의 오버헤드 바이트 및 CRC(Cyclic Redundancy Check) 필드를 고려하지 않기 때문입니다.따라서 라인 레이트로 셰이핑하는 것은 실제로 오버서브스크립션되며 인터페이스 혼잡을 유발합니다.액세스 속도로 셰이핑하는 것은 권장되지 않습니다.항상 액세스 속도의 95%로 트래픽을 조정해야 합니다.일반적으로 집계 모양은 액세스 속도의 95%를 넘지 않아야 합니다.
이 섹션에는 이 문서에서 설명하는 기능을 구성하기 위한 정보가 표시됩니다.
참고: 이 문서에서 사용되는 명령에 대한 추가 정보를 찾으려면 IOS 명령 조회 도구를 사용하십시오.
이 문서에서는 다음 네트워크 설정을 사용합니다.
위의 예에서는 다음 값을 가집니다.
허브 - 액세스 속도 = 192Kbps, 보장 속도 = 32Kbps
원격 - 액세스 속도 = 64Kbps, 보장 속도 = 32Kbps
여기서는 평균 전송 속도가 64Kbps가 되도록 양쪽 끝에서 트래픽 셰이핑을 구현합니다.필요한 경우 HUB가 이 이상으로 버스트될 수 있습니다.혼잡이 발생할 경우 최소 32Kbps까지 떨어질 수 있습니다.클라우드의 혼잡 알림은 BECHN(backward explicit congestion notification)을 통해 이루어집니다. 따라서 쉐이핑은 BECN에 적응하도록 구성됩니다.
참고: 프레임 릴레이 트래픽 셰이핑은 기본 인터페이스에서 활성화되며 해당 인터페이스의 모든 DLCI(데이터 링크 연결 식별자)에 적용됩니다.기본 인터페이스 아래의 특정 DLCI 또는 하위 인터페이스에 대해서만 트래픽 셰이핑을 활성화할 수 없습니다.특정 DLCI에 연결된 맵 클래스가 없고 기본 인터페이스에서 트래픽 셰이핑이 활성화된 경우 DLCI에는 CIR = 56000의 기본 맵 클래스가 할당됩니다.
이 문서에서는 다음 구성을 사용합니다.
허브
원격
허브 |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping !--- Apply traffic shaping to main interface (step 3). interface Serial0/0.1 point-to-point ip address 10.1.1.1 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco !--- Apply map class to the DLCI / subinterface (step 2). ! ! !--- Configure map class parameters (step 1). map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 frame-relay be 16000 ! |
원격 |
---|
interface Serial0/0 no ip address encapsulation frame-relay no fair-queue frame-relay traffic-shaping ! interface Serial0/0.1 point-to-point ip address 10.1.1.2 255.255.255.0 frame-relay interface-dlci 16 frame-relay class cisco ! map-class frame-relay cisco frame-relay cir 64000 frame-relay mincir 32000 frame-relay adaptive-shaping becn frame-relay bc 8000 ! |
다음 다이어그램은 HUB 라우터에서 전송되는 트래픽을 보여줍니다.
트래픽이 버스트 80000비트와 함께 전송된다고 가정할 때, 이는 8Tc 간격(각각 125msec)으로 PVC에서 전송됩니다. 첫 번째 간격에서 사용 가능한 크레딧은 Bc + Be = 8000 + 16000 = 24000비트이므로 이를 달성할 수 있습니다.이는 속도가 24,000비트/125msec = 192Kbps임을 의미합니다.
다음 7개 간격에서는 Bc = 8000비트만 사용됩니다.따라서 속도는 8000/125msec = 64Kbps입니다.
예를 들어, 버스트가 88000비트로 수신되면 이 모든 트래픽을 8Tc 간격으로 전송할 수 없습니다.마지막 8000비트는 9번째 Tc 간격으로 전송됩니다.따라서 이 트래픽은 트래픽 셰이핑 메커니즘에 의해 지연됩니다.
이 섹션에서는 컨피그레이션이 제대로 작동하는지 확인하는 데 사용할 수 있는 정보를 제공합니다.
일부 show 명령은 출력 인터프리터 툴 에서 지원되는데(등록된 고객만), 이 툴을 사용하면 show 명령 출력의 분석 결과를 볼 수 있습니다.
show frame relay pvc <dlci> 명령을 사용하여 컨피그레이션 세부 정보를 봅니다.
Hub#show frame relay pvc 16 PVC Statistics for interface Serial0/0 (Frame Relay DTE) DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1 input pkts 8743 output pkts 5 in bytes 2548330 out bytes 520 dropped pkts 0 in FECN pkts 0 in BECN pkts 0 out FECN pkts 0 out BECN pkts 0 in DE pkts 0 out DE pkts 0 out bcast pkts 0 out bcast bytes 0 Shaping adapts to BECN pvc create time 6d01h, last time pvc status changed 6d01h cir 64000 bc 8000 be 16000 byte limit 3000 interval 125 mincir 56000 byte increment 1000 Adaptive Shaping BECN pkts 5 bytes 170 pkts delayed 0 bytes delayed 0 shaping inactive traffic shaping drops 0 Queueing strategy: fifo Output queue 0/40, 0 drop, 0 dequeued
이는 트래픽 셰이핑 메커니즘이 활성화되었는지 여부를 실시간으로 보여줍니다.트래픽 셰이핑은 다음 시나리오에서 활성화됩니다.
BECN이 수신되고 DLCI가 BECN에 셰이핑되도록 구성되었습니다.
인터페이스에서 전송할 데이터 바이트 수가 지정된 간격(Tc)에서 사용 가능한 신용(바이트 제한)보다 많습니다.
FRF.12 프래그먼트화가 구성되었으며 패킷이 프래그먼트화될 때까지 대기 중입니다.
트래픽 셰이핑 메커니즘의 활성화로 인해 지연된 패킷 및 바이트 수를 표시합니다.이는 주로 전송할 바이트 수가 간격당 사용 가능한 크레딧을 초과하거나 패킷을 프래그먼트화해야 하는 경우(FRF.12) 적용됩니다. 이러한 패킷 및 바이트는 셰이핑 큐(VC당 할당)에 저장된 다음 사용 가능한 크레딧이 충분히 있을 때 후속 간격으로 전송됩니다.
셰이핑 큐의 삭제 수를 표시합니다.바이트는 먼저 셰이핑 메커니즘에 의해 지연되며 이 대기열에 저장됩니다.대기열이 가득 차면 패킷이 삭제됩니다.기본적으로 대기열 유형은 FCFS(First Come First Serve) 또는 FIFO이지만 WFQ, PQ, CQ, CBWFQ 또는 LLQ로 변경할 수 있습니다.관련 정보 참조
개정 | 게시 날짜 | 의견 |
---|---|---|
1.0 |
31-May-2005 |
최초 릴리스 |