터널별 QoS는 허브의 전체 업링크를 제한하지 않습니다

이 믿음은 산수처럼 들립니다. 스포크 다섯 개를 각각 5 Mbit/s로 셰이핑했으니 허브는 최대 25 Mbit/s를 나른다는 것입니다. 앞부분은 맞고 결론은 틀립니다. 터널별 정책은 허브당 한 번이 아니라 터널당 한 번 적용되며, 다섯 터널이 모두 지나는 공유 업링크는 그 계산에 전혀 나타나지 않습니다. 업링크의 혼잡은 그대로 남습니다.

믿음이 생기는 곳

혼란은 이해할 만합니다. NHRP 그룹 정보를 쓰면 하나의 정책 정의를 스포크 집합 전체에 적용할 수 있기 때문입니다. 이는 구성 파일의 공유 예산처럼 읽힙니다. 실제 의미는 각 스포크가 그 정의의 인스턴스를 따로 받는다는 것입니다.

따라서 스포크당 5 Mbit/s는 터널별 상한이고, 상한의 수는 터널의 수와 같습니다.

정책 인스턴스 하나가 제어하는 것

Cisco의 IOS XE에서의 DMVPN 터널별 QoS 안내서는 NHRP 그룹 정보로 선택되어 각 스포크에 개별 적용되는 허브 이그레스 정책을 설명합니다. 이 문장에서 두 가지 한계가 나오고 둘 다 무시됩니다. 속도는 공유 양동이가 아니라 한 스포크에 속하며, 이 기능은 허브에서 스포크로 가는 트래픽을 제어하며 그 반대가 아닙니다.

스포크의 전송 방향은 독립적으로 계획하세요. 허브 이그레스 정책에는 지사가 업로드하는 것을 제한하는 요소가 없습니다.

집계 한도를 공유 병목에 두세요

집계는 실제로 경쟁하는 지점에서 셰이핑되어야 합니다. 그러나 모든 터널이 공유하는 물리 인터페이스입니다. Cisco는 이 기능에 지원되는 동시 물리 정책으로 물리 인터페이스의 class-default 셰이퍼를 문서화합니다. 이는 입력할 수 있는 어떤 계층 구조보다 좁은 진술이며, 직접 만든 임의의 두 번째 물리 정책은 누군가 반증할 때까지 지원되지 않는다고 가정하세요.

그다음 모든 스포크가 동시에 바쁠 때 무슨 일이 일어나는지 정하세요. 어떤 트래픽이 허용되고, 어느 클래스가 우선되며, 어느 큐가 경쟁을 맡는지입니다. 스포크별 상한은 이런 질문에 하나도 답하지 않습니다. 각 스포크를 따로 보기 때문입니다.

셰이핑 단위와 오버헤드 회계를 실제 핸드오프에 맞추세요. 속도 계산에서 빼놓은 캡슐화 오버헤드는 설정한 숫자보다 먼저 포화되는 링크로 나타납니다.

카운터는 한 가지 방식으로 거짓말합니다

셰이핑하는 계층에서 카운터를 읽으세요. 같은 Cisco 안내서는 이 구성에서 메인 인터페이스 정책 카운터가 부정확할 수 있다고 경고합니다. 그것은 카운터에 대한 주의이지 클래스가 일치하거나 버린다는 증거가 아닙니다. 애플리케이션 결과와 분리해 두세요. 사용자가 겪는 것은 그것뿐입니다.

오래된 traffic-shape 예제를 무관한 정책 맵 옆에 복사하는 것은 두 속도가 같은 패킷을 제어한다는 증거가 아닙니다.

상한이 아니라 집계를 시험하세요

바쁜 스포크 하나로 시작해 상한에 도달하는지 확인하세요. 그다음 승인된 계획에 따라 모든 스포크에서 동시에 트래픽을 보내고, 터널별 수치 옆에서 물리 인터페이스를 지켜보세요. 각 스포크가 상한에 머무는데 업링크가 꽉 차고 지연이 올라간다면, 스포크별 정책은 설계대로 동작하고 있으며 예산은 여전히 틀린 것입니다.

그 시점의 해결책은 용량이나 수용 결정입니다. 스포크별 수치를 다시 조정하는 것은 어느 지사가 먼저 불평하는지만 바꿉니다.