저는 현재 ISP 수준의 회사를위한 트래픽 쉐이핑 솔루션을 개발 중이며 흥미로운 (철학적 인) 문제에 직면했습니다.
시스템이 처리해야하는 엔드 포인트 수 (약 20k 정도)를 살펴보면 더 많은 사용자의 트래픽을 정책 / 형성해야 할 때 어떤 일이 발생할지 걱정이되었습니다. 현재 전체 네트워크에 대해 HFSC 쉐이핑 트리 (주로 잘 알려진 HTB와 동일하지만 쿨러 인 tc-hfsc 참조)를 사용하고 있으므로 더 많은 ClassID를 사용해야합니다 (분명히 각 사용자마다 하나 이상). 회로망). 내가 찾은 문제는 TC ClassID가 제한적이라는 것입니다 .16 비트 숫자 이므로이 솔루션으로 최대 64k 사용자를 만들 수 있습니다.
마찬가지로 TC 필터를 효율적으로 관리하려면 (예 : '모든 기능 플러시'를 사용하지 않음) 개별 필터 항목을 삭제하거나 수정할 수 있어야합니다. (LARTC [1]의 해시 테이블과 비슷한 것을 사용하고 있습니다). 다시 말하지만, 이것과 함께 작동하는 유일한 방법은 개별 우선 순위 (tc filter add dev ... prio 1)를 사용하여 모든 필터에 번호를 매기는 것입니다. 이 목적으로 사용될 수있는 다른 매개 변수는 없으며, 유감스럽게도 prio는 16 비트 전용입니다.
내 질문은 다음과 같습니다 : 'tc class'명령에 대한 32 비트 clsid 및 'tc 필터'에 대한 32 비트 우선 순위 (또는 다른 수정 핸들)와 같이 사용 가능한 "식별자 공간"을 확대하는 좋은 방법이 있습니까? 명령?
매우 감사합니다,
-mk
(하지만 이것이 "64k 사용자는 모든 사람에게 충분해야 함"시나리오로 가지 않기를 바랍니다 ...)