☰

htb 클래스에서 qdisc prio 사용

tag-icon • tag-icon networking bandwidth tc qos
htb 클래스에서 qdisc prio 사용

동일한 인터페이스를 통해 실행되는 2개의 서비스가 있습니다.
서비스 목표는 많은 양의 데이터를 전송하면서 높은 대역폭을 유지하는 것입니다.
서비스 B는 낮은 대기 시간을 목표로 합니다.

서비스 B 패킷은언제나지원 서비스 패킷.
다음을 수행하려면 TC 구조가 필요합니다.

  • 속도 제한 서비스 A 및 B
  • 서비스 B 패킷에 우선순위를 부여하면 서비스 A 패킷은 대기 시간에 0% 영향을 미칩니다.
  • 다른 서비스가 전송되지 않는 경우 각 서비스가 전체 회선을 활용하거나 한계에 도달하도록 합니다.

class htb classid x나는 속도/상한 제한이 있을 수 있고 (예: y:0을 처리) 자식으로(자동으로 클래스 y:1, y:2 및 y:3을 생성함) 필터 src ip 리디렉션을 사용할 수 있는 htb 구조를 qdisc prio시도했습니다. 패킷을 y:1/y:2로 보냅니다.
그러나 작동하지 않는 것 같습니다. 및 해당 하위 흐름은
모두 class x0으로 나타납니다. ( tc -s class/qdisc/filter show dev dev보기용)
필터를 볼 때 "클릭"을 명확하게 볼 수 있으므로 데이터가 올바르게 리디렉션되어야 합니다.

내가 실행한 명령은 다음과 같습니다.

tc qdisc add dev dev root handle 1: htb
tc class add dev dev parent 1:0 classid 1:1 htb rate 10gbit ceil 10gbit
# class x
tc class add dev dev parent 1:1 classid 1:2 htb rate 10gbit ceil 10gbit
# auto creates classes 21:1, 21:2 and 21:3
tc qdisc add dev dev parent 1:2 handle 21: prio
# example for service b filter (latency driven)
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:1
# example for service a filter
tc filter add dev dev parent 1:0 prio 2 u32 match ip src x.x.x.x/32 flowid 21:2

답변1

오랫동안 이런 일을 해본 적이 없었습니다. 제 대답을 냉소적으로 받아들이십시오.

필터 상위는 아마도 PRIO qdisc 자체여야 합니다(따라서 HTB 필터와 PRIO 필터가 있습니다...). 그렇지 않으면 PRIO는 priomap을 기반으로 패킷 자체를 재분류할 수 있습니다.

이것이 내 이전 스크립트의 모습입니다(FairNAT, GitHub에서 모든 것을 찾을 수 있습니다). 당시에는 제대로 작동했다고 확신합니다... 이 경우 패킷은 IP로 필터링되지 않았지만 iptables로 플래그가 지정되었습니다. IP 필터가 신뢰할 수 없다고 의심되면 시도해 보세요.

# Create a prio qdisc with 4 classes. All P2P traffic goes into class 4.
        $BIN_TC qdisc add dev $UC_DEV parent 1:$UC_MARK handle $UC_MARK: prio \
                          bands 4

# Add a filter for IPP2P to this qdisc. The rest depends on TOS.
        $BIN_TC filter add dev $UC_DEV parent $UC_MARK: protocol ip \
                       handle $(($UC_MARK+1)) fw flowid $UC_MARK:4

PRIO대부분의 경우 좋은 선택이 아닙니다. 이는 매우 공격적이어서 다른 모든 트래픽을 완전히 소모할 수 있습니다.

HTB 클래스가 하나만 있으면 원하는 결과를 얻지 못할 수도 있습니다. 10GE로 제한된다는 것도 나에게는 약간 이상하게 들립니다. 이것이 이론적 링크 속도이고 실제로 달성되지 않은 경우에는 아무 것도 하지 않습니다.

HFSC이 작업에 더 적합할 수 있습니다. 문서화는 HTB보다 훨씬 나쁩니다. 하지만 속도 제한과 우선순위 지정 작업은 더 잘 수행합니다(HTB는 어떤 것에도 우선순위를 지정하지 않습니다).

관련 정보