직렬 인터페이스의 출력 감소 : 더 나은 큐잉 또는 출력 큐 크기?

eBGP를 여러 캐리어에, iBGP를 서로 통신하는 인터넷 에지 라우터에서 LAN 및 WAN 쪽의 모든 인터페이스는 각 라우터에서 하나의 Serial full-DS3 (~ 45Mbps)를 제외하고 GE입니다. 3-10Mbps 범위의 직렬 인터페이스에서 많은 트래픽을 아웃 바운드로 전송하는 것은 거의 불가능하지만 OQD (constant output queue drop)가 표시됩니다. 로드 간격이 최소 30 초이고 SNMP 폴링이 평균 5 분 동안 트래픽을 평균 할 때 표시되지 않는 버스트 트래픽이 실제로있을 가능성이있는 설명 입니까?

플랫폼은 Cisco 7204VXR NPE-G2입니다. 시리얼 큐잉은 fifo 입니다.

Serial1 / 0이 작동 중이고 회선 프로토콜이 작동 중임
  하드웨어는 M2T-T3 + pa
  설명 :-제거됨-
  인터넷 주소는 abcd / 30입니다
  MTU 4470 바이트, BW 44210 Kbit, DLY 200 usec,
     신뢰성 255/255, txload 5/255, rxload 1/255
  캡슐화 HDLC, crc 16, 루프백이 설정되지 않음
  Keepalive 세트 (10 초)
  재시작 지연은 0 초입니다
  마지막 입력 00:00:02, 출력 00:00:00, 출력 중단 없음
  "표시 인터페이스"카운터의 마지막 지우기 00:35:19
  입력 큐 : 0/75/0/0 (크기 / 최대 / 드롭 / 플러시); 총 출력 하락 : 36
  큐 전략 : fifo
  출력 대기열 : 0/40 (크기 / 최대)
  30 초 입력 속도 260000 비트 / 초, 208 패킷 / 초
  30 초 출력 속도 939000 비트 / 초, 288 패킷 / 초
     410638 패킷 입력, 52410388 바이트, 0 버퍼 없음
     방송 212 개, 런트 0 개, 자이언트 0 개, 스로틀 0 개 수신
              0 패리티
     0 입력 오류, 0 CRC, 0 프레임, 0 오버런, 0 무시, 0 중단
     515752 패킷 출력, 139195019 바이트, 0 언더런
     출력 오류 0 개, 아플리케 0 개, 인터페이스 재설정 0 개
     0 출력 버퍼 오류, 0 출력 버퍼 스왑 아웃
     0 캐리어 전환
   rxLOS 비활성, rxLOF 비활성, rxAIS 비활성
   txAIS 비활성, rxRAI 비활성, txRAI 비활성

24 시간 후에 수천 개의 OQD가 표시됩니다. 우리는 매일 오전 3 시경에 더 많은 트래픽을 내 보냅니다.

Last clearing of "show interface" counters 1d01h
Input queue: 0/75/0/158 (size/max/drops/flushes); Total output drops: 12049

DS3에서 더 많은 아웃 바운드 트래픽을 추진하고 싶지만 OQD에 대한 우려는 없습니다. DS3 뒤의 2 티어 ISP에는 6+ 티어 1의 피어링 포인트로 2 배가되는 POP가 있으므로 1 티어 인 GE의 1 차 ISP와 반대로 클라이언트와의 인터넷 트래픽을 최대한 빨리 얻는 것이 좋습니다. 그러나 동료 교환을 위해 노력해야합니다. 인바운드 트래픽은 문제가되지 않습니다.

이 상황에서 fifo보다 더 나은 큐잉 전략이 있습니까? 입력 및 출력 대기열 삭제에 대한 Cisco 문서를 살펴보면 패킷이 이미 라우터에 있기 때문에 아웃 바운드 대기열 크기를 늘리는 것은 권장되지 않으며 TCP가 앱을 다시 조절할 수 있도록 입력에서 삭제하는 것이 좋습니다. GE 링크에는 충분한 대역폭이 있으므로 입력을 조절할 필요가 없습니다. 이 라우터에는 정책 맵이 없습니다. 아웃 바운드 트래픽의 90 %는 HTTP 응답에서 비롯됩니다. FTP와 SMTP의 나머지 대부분. GE 링크는 50-200 + Mbps를 푸시합니다.

출력 대기 행렬 크기 버퍼에 대한 조정을 권장 하시겠습니까? 이 직렬 인터페이스는 이전에 제공된 이유로 더 유용하게 사용되는 백업 링크입니다 (유효한 경우). 그러나 직렬 인터페이스에 과부하가 걸리지 않는 BGP 정책으로 강화되었습니다 (대부분의 경우 너무 많이로드 됨).

맞습니다. SNMP에서 버스트를 쉽게 볼 수는 없습니다. 1GE는 1.48Mpps를 전송할 수 있으므로 45Mbps를 정체하는 데 시간이 거의 걸리지 않아 75kpps 미만을 처리 할 수 ​​있습니다.

수신이 1GE이고 송신이 45Mbps이면 혼잡 지점 45Mbps는 패킷을 삭제해야합니다. 이것은 정상이며 예상됩니다. 버퍼를 늘리면 더 많은 지연이 발생합니다.
1GE는 40 1500B IP 프레임을 전송하는 데 0.45ms가 걸리며 현재 처리 할 수있는 버스트 양입니다. 그러나 45Mbps에서 대기열을 제거하는 데는 이미 10ms가 걸립니다.

심각한 문제가 없다면 아마도 아무 것도하지 않을 것입니다. 그러나 일부 트래픽이 다른 트래픽보다 드롭 할 수있는 경우 FIFO를 클래스 기반 큐로 바꿔야합니다. 더 많은 ftp가 삭제되고 voip가 줄어들도록 우선 순위를 정하고 싶을 수도 있습니다.
그리고 지연에 민감하지 않기 때문에 ftp 트래픽에 더 많은 버퍼링을 추가하는 것이 더 합리적입니다.

더 깊은 버퍼로 운을 시험 해보고 싶다면 다음과 같이 충분합니다.

policy-map WAN-OUT
 class class-default
    fair-queue
    queue-limit 200 packets
!
interface Serial1/0
  service-policy output WAN-OUT

이로 인해 Serial1에서 50ms 버퍼가 발생하고 단일 Gige 인터페이스에서 최대 2.25ms 버스트를 처리 할 수 ​​있습니다.

OQD는 일반적으로 다음 두 가지 중 하나에 의해 발생합니다.

1. 링크를 사용하고 있습니다. 지속적으로 사용량이 많거나 사용량이 많은 트래픽.

2. 트래픽의 일부 또는 전체를 폴리싱하거나 형성하는 등의 작업을 수행하도록 구성된 정책 맵이 인터페이스에 적용되었습니다.

3. 인터페이스에 어떤 종류의 오류가 있습니다. 오류 카운터 ( show interface Serial1/0 counters errors)를 보고 오류 로 인해 패킷이 삭제되지 않는지 확인하십시오.

미션 크리티컬 트래픽에 자체 대기열을 제공하거나 정기 트래픽 (WRED)에서 정체 방지를 사용하거나 트래픽에 대해 공정한 큐잉을 수행하는 등의 작업을 수행하기 위해 정책 맵을 배치 할 수 있습니다 (아직없는 경우). 인터페이스를 전송하는 흐름간에 대역폭이 공유됩니다.

앞에서 언급했듯이 인터페이스에서 출력 큐 크기를 늘리는 다른 옵션이 있지만 정책 맵을 사용하는 경우 정책에서 다른 하위 큐를 생성하므로이 옵션이 필요하지 않습니다.